Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites

[mono.riot--- via dev-security-policy]

> I've been wondering if CT is a good tool for things like safe
> browsing to monitor possible phishing sites and possibly detect
> them faster.

Are there general proposals yet on how to distinguish phishing vs legitimate 
when it comes to domains? (like apple.com vs app1e.com vs mom'n'pop farmer's 
myapple.com)

Thanks,

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

Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites

[Peter Gutmann via dev-security-policy]

Martin Heaps via dev-security-policy  
writes:

>This topic is frustrating in that there seems to be a wide attempt by people
>to use one form of authentication (DV TLS) to verify another form of
>authentication (EV TLS).

The overall problem is that browser vendors have decreed that you can't have
encryption unless you have a certificate, i.e. a CA-supplied magic token to
turn the crypto on.  Let's Encrypt was an attempt to kludge around this by
giving everyone one of these magic tokens.  Like a lot of other kludges, it
had negative consequences...

So it's now being actively exploited... how could anyone *not* see this
coming?  How can anyone actually be surprised that this is now happening?  As
the late Bob Jueneman once said on the PKIX list (over a different PKI-related
topic), "it's like watching a train wreck in slow motion, one freeze-frame at
a time".  It's pre-ordained what's going to happen, the most you can do is
artificially delay its arrival.

>The end nessecity is that the general public need to be educated [...]

Quoting Vesselin Bontchev, "if user education was going to work, it would have
worked by now".  And that was a decade ago.

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

Re: Grace Period for Sub-CA Disclosure

[Jakob Bohm via dev-security-policy]

On 28/03/2017 00:16, Ben Wilson wrote:

What if the third party needs to review the certificate to see whether it
meets expected profile requirements?  In some cases the certificate subject
must first "accept" the certificate.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Jakob Bohm via dev-security-policy
Sent: Monday, March 27, 2017 3:58 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Grace Period for Sub-CA Disclosure

On 27/03/2017 23:41, Rob Stradling wrote:

On 27/03/17 22:37, Jakob Bohm via dev-security-policy wrote:


It should also be made a requirement that the issued SubCA
certificate is provided to the CCADB and other root programs before
providing it to the SubCA owner/operator,


That'd be a bit difficult in the common case where the Sub-CA operator
and the Sub-CA certificate's issuer are the same entity!



Oops forgot to include "3rd party" in that sentence.  This extra requirement
would only apply to 3rd party SubCA signing, as well as to SubCA signing for
a different part of the same organization.

It should not apply where the new SubCA is located in the same place and
receives the SubCA cert as part of the same high security signing ceremony.




Even if the subject rejects a provided certificate, the subject can
still use it (subject to revocation checking).

Thus for browsers that have replaced actual revocation checking by
things like OneCRL, disclosure of such a rejected SubCA certificate is
still required.


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: Grace Period for Sub-CA Disclosure

[Jakob Bohm via dev-security-policy]

On 27/03/2017 23:41, Rob Stradling wrote:

On 27/03/17 22:37, Jakob Bohm via dev-security-policy wrote:


It should also be made a requirement that the issued SubCA certificate
is provided to the CCADB and other root programs before providing it to
the SubCA owner/operator,


That'd be a bit difficult in the common case where the Sub-CA operator
and the Sub-CA certificate's issuer are the same entity!



Oops forgot to include "3rd party" in that sentence.  This extra
requirement would only apply to 3rd party SubCA signing, as well as to
SubCA signing for a different part of the same organization.

It should not apply where the new SubCA is located in the same place
and receives the SubCA cert as part of the same high security signing
ceremony.



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: Google Trust Services roots

[okaphone.elektronika--- via dev-security-policy]

It's probably my ignorance in these matters, but how does purchasing a root 
certificate affect revocation?

Will that remain the responsibility of GlobalSign for any existing certificates 
that have been signed with these roots? (Those would be intermediate 
certificates, if I understand correctly.) Or does revocation also require 
signing, and does it therefore become the responsibility of the new owner of 
the roots?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Grace Period for Sub-CA Disclosure

[Andrew Ayer via dev-security-policy]

[ Corresponding issue on GitHub: https://github.com/mozilla/pkipolicy/issues/67 
]

Mozilla's CA Certificate Policy says:

> All certificates that are capable of being used to issue new
> certificates, that are not technically constrained, and that directly
> or transitively chain to a certificate included in Mozilla's CA
> Certificate Program MUST be audited in accordance with Mozilla's CA
> Certificate Policy and MUST be publicly disclosed in the CCADB by the
> CA that has their certificate included in Mozilla's CA Certificate
> Program.

One cannot disclose a sub-CA certificate without first signing it, so
there will always be some delay between the creation of a sub-CA and
its disclosure in the CCADB.  How long can a CA delay the disclosure?
All the policy currently says is this:

> The CA with a certificate included in Mozilla's CA Certificate
> Program MUST disclose this information before any such subordinate CA
> is allowed to issue certificates.

My interpretation of the policy is that a CA could delay disclosure for
quite some time if the sub-CA is not used to issue certificates right
away.  If the sub-CA is created as a backup that is never used, the
disclosure would never need to happen.

I think this is bad.  An upper limit on the delay should be precisely
specified by the policy.  My opinion is that it should be on the order
of days, although the policy might need to afford some leeway to CAs
that are new to the Mozilla program and do not have access yet to CCADB.

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

Re: Question: Transfering the private key of an EV-approved CA

[Ryan Sleevi via dev-security-policy]

On Mon, Mar 27, 2017 at 3:09 PM, Kai Engert via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Are there existing rules, in the CABForum BRs, or in the Mozilla CA
> policy, that
> define under which circumstances the private key of an actively used EV
> approved
> root CA may be transferred to a different company, that hasn't been
> audited for
> EV compliance?
>

A root CA is not simply approved for EV. A root CA has one or more policies
that indicate compliance with EV, and those policies are recognized for the
associated root certificates.

To your question, no, there are no policies _specific to EV_ related to
that. The general Mozilla Policy handling all root key transfer and
cross-certifications applies.


> As soon as the private key has been given to another company, the receiving
> company technically has the ability to issue EV certificates (even if they
> never
> intend to do so), right?
>

Correct, but as per the above, the actual _use_ of that is governed by the
CP/CPS and associated audits, no different than any other CA.


> I would have naively assumed that a company, that owns an EV approved
> CA, is
> expected to strictly protect their EV issuing power, and must never share
> it
> with another company that hasn't been approved for issuing EV certificates.
>

That's not stated in any special case for EV. In fact, even without the
transfer of root key material, it's possible for an EV-enabled root to
cross-certify another CA for EV issuance, by authorizing them for the
relative certificate policies. It is incumbent upon the issuing CA to
ensure that subordinated CA's policies and practices are wholly aligned
with the parent CA's CP/CPS.


> If this makes sense, and if there aren't any rules yet, I suggest to add
> them to
> the appropriate policy documents.
>

Given the bug you were asking questions on "this morning",
https://bugzilla.mozilla.org/show_bug.cgi?id=1349727 , it sounds like this
is related to the discussion on
https://groups.google.com/d/msg/mozilla.dev.security.policy/1PDQv0GUW_s/oxDWH07VDgAJ
, which has significantly more details on this, including statements from
various Mozilla peers and module owners.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites

[Kurt Roeckx via dev-security-policy]

On Mon, Mar 27, 2017 at 09:02:48PM +0100, Gervase Markham via 
dev-security-policy wrote:
> On 27/03/17 16:08, Martin Heaps wrote:
> > The next level is now that any business or high valued entity should
> > over the course of the next few years implement EV certificates (many
> > already have) and that browsers should make EV certificates MORE
> > noticable on websites..
> 
> or we should decide that the phishing problem is not best solved at
> the level of certificates, but instead at a higher level (e.g. Safe
> Browsing and similar mechanisms).

I've been wondering if CT is a good tool for things like safe
browsing to monitor possible phishing sites and possibly detect
them faster.


Kurt

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

Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites

[Gervase Markham via dev-security-policy]

On 27/03/17 16:08, Martin Heaps wrote:
> The next level is now that any business or high valued entity should
> over the course of the next few years implement EV certificates (many
> already have) and that browsers should make EV certificates MORE
> noticable on websites..

or we should decide that the phishing problem is not best solved at
the level of certificates, but instead at a higher level (e.g. Safe
Browsing and similar mechanisms).

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

Question: Transfering the private key of an EV-approved CA

[Kai Engert via dev-security-policy]

Are there existing rules, in the CABForum BRs, or in the Mozilla CA policy, that
define under which circumstances the private key of an actively used EV approved
root CA may be transferred to a different company, that hasn't been audited for
EV compliance?

As soon as the private key has been given to another company, the receiving
company technically has the ability to issue EV certificates (even if they never
intend to do so), right?

I would have naively assumed that a company, that owns an EV approved CA, is
expected to strictly protect their EV issuing power, and must never share it
with another company that hasn't been approved for issuing EV certificates.

If this makes sense, and if there aren't any rules yet, I suggest to add them to
the appropriate policy documents.

Thanks
Kai

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

Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites

[Martin Heaps via dev-security-policy]

This topic is frustrating in that there seems to be a wide attempt by people to 
use one form of authentication (DV TLS) to verify another form of 
authentication (EV TLS). 

There seems an issue for people not being able to understand that a FREE 
service with a vey low bar in knowledge requirement on the part of the end user 
(the website owner) will be used across the spectrum of human achievement (good 
and bad).

Economics: If something costs money, they far fewer people will make use of it, 
this has been (one of) the core reasonings behind "Lets Encrpyt" and other free 
SSL service providers. 

Education: If something requires a skill and background knowledge to work 
properly and correctly then far fewer people will be willing to deploy it 
across their websites.

The next level is now that any business or high valued entity should over the 
course of the next few years implement EV certificates (many already have) and 
that browsers should make EV certificates MORE noticable on websites. 

BUT:
The end nessecity is that the general public need to be educated that a 
"secure" website does not mean an "authenticated" business, person or 
organisation. The general public needs to be aware of the difference between a 
DV and EV certificate. 

The community has spent meany years trying to highlight that lack of secure 
SSL/TLS for websites, that now it's in place, the community needs to highlight 
the different *Types* of certificates available and what they mean for the 
website visitor.

In addition I think this topic seems to be highlighted as an excuse by parties 
who (for some reason) don't like Lets Encrypt and similar services and want to 
use it as a way for people who don't understand what DV TLS actually does, to 
use it to draw attention to others who do not know what DV TLS does, to 
highlight that Lets Encrypt is somehow Bad or Evil for providing a secure 
service for nefarious websites.

Some ideas:

1) Browsers can gradually make the EV certificates more prominent, something 
such as first time a site is visited with an EV certificate that a popup notice 
appears declaring the name and address of the owner of the site. 

2) Websites themselves need to deploy better Content Security Policy practises. 
Very few websites seem to be using CSP despite it being a very powerful and 
flexible tool for preventing any site masqurading as another by "borrowing" 
their media and contents.  

3) There could be a system of word recognition / repetition count for something 
such as browse plugins to detect websites that use the "Paypal" word for 
instance above a certain level and then notifying the user the site is NOT an 
actual paypal domain.

(sorry, I'm sure most of you reading this are well aware of the details, I 
wanted a bit of a vent)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Ryan Sleevi via dev-security-policy]

Clarified on the new thread you started, but I don't believe there's any
inconsistency. Further details on the new thread you started.

On Mon, Mar 27, 2017 at 10:02 AM, Roland Fantasia via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Anyone care to comment on the fact that Google's new subCAs under the GTS
> branding have inconsistent EKU and KU bits? What's more disturbing is FF
> doesn't make a fuss about it when connecting to the test sites (after
> adding the roots manually of course).
> ___
> 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: EKU in Google sub CAs in violation of RFC5280?

[Ryan Sleevi via dev-security-policy]

On Mon, Mar 27, 2017 at 9:45 AM, tpg0007--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On https://pki.goog, all 5 of Google's newer subCAs have Extended Key
> Usage extension of serverAuth and clientAuth, unusual for CAs but not
> forbidden I guess. Their Key Usage extension contains the expected cert and
> CRL sign bits. Put together though they appear to be noncompliant with RFC
> 5280 4.2.1.12, which states that if both extensions are present then the
> certificate should not be used for any purpose unless that purpose is
> consistent across both extensions. The digitalSignature key usage that
> might make them consistent with the above EKU is clearly not present.
>

This sounds like a misunderstanding over the RFCs, rather than a violation.

While you highlight the presence of EKUs as unusual, but not forbidden,
it's actually quite usual, and something that both Microsoft and Mozilla
have explored mandating in the past. You can find lots of discussion within
the IETF PKIX WG going over 10 years on this matter, but effectively, an
EKU within an intermediate acts as a constraint upon the EKUs of
certificates it issues. That is, it behaves similar to Certificate Policies
by describing an 'effective' EKU set.

Virtually every major PKI library deployed as part of the Web PKI
recognizes this, and uses it as an effective way to scope the issuance of
types of certificates. That is, if an intermediate contains an EKU
extension, does not contain the any EKU identifier, and contains EKUs other
than serverAuthentication, then these libraries WILL NOT accept
certificates issued by these sub-CAs as valid for serverAuthentication.

To this end, the purpose of Certificate Signatures is entirely consistent.

The digitalSignature purpose, as a key usage, as it is used in TLS, relates
to the ciphersuites employed.

Thus, this is also not a contradiction to 5280.

Does that help explain?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Next CA Communication

[Ryan Sleevi via dev-security-policy]

On Mon, Mar 27, 2017 at 10:18 AM, Ryan Sleevi  wrote:

> Gerv,
>
> I'm curious whether you would consider 18 months an appropriate target for
> a deprecation to 1 year certificates. That is, do you believe a transition
> to 1 year certificates requires 24 months or 18 months, or was it chosen
> simply for its appeal as a staggered number (1 year -> 2 year certs, 2
> years -> 1 year certs)
>

I suppose one further consideration - the proposal you outline would forbid
issuance. As we saw with the SHA-1 deprecation, there are a variety of PKI
communities which may rely on long-lived certificates for other purposes,
but otherwise in no way interact with Mozilla applications.

Would it be useful to thus also query whether there would be impact in
Mozilla applications failing to trust such certificates, but otherwise to
continue permitting their issuance. While this carries with it some
compatibility and interoperability risk - due to the issuance continuing
independent of applications - I suspect that if applications could agree
upon a target date to reduce the trust in acceptance, this might be a
sufficient safeguard against the "first mover" problem and allow Mozilla to
obtain its objectives without explicitly prohibiting issuance.

That is a separate, but related, question, but useful to consider if you
will be asking all CAs, some of whom may have reasons due to other PKIs
that would make them concerned about potential impact. However, if
Mozilla's goals and desires would include seeing those PKIs are operated
independently of the Web PKI, then forbidding issuance would be appropriate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Roland Fantasia via dev-security-policy]

Anyone care to comment on the fact that Google's new subCAs under the GTS 
branding have inconsistent EKU and KU bits? What's more disturbing is FF 
doesn't make a fuss about it when connecting to the test sites (after adding 
the roots manually of course).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

EKU in Google sub CAs in violation of RFC5280?

[tpg0007--- via dev-security-policy]

On https://pki.goog, all 5 of Google's newer subCAs have Extended Key Usage 
extension of serverAuth and clientAuth, unusual for CAs but not forbidden I 
guess. Their Key Usage extension contains the expected cert and CRL sign bits. 
Put together though they appear to be noncompliant with RFC 5280 4.2.1.12, 
which states that if both extensions are present then the certificate should 
not be used for any purpose unless that purpose is consistent across both 
extensions. The digitalSignature key usage that might make them consistent with 
the above EKU is clearly not present.

I'm posting this here because 1) not sure where else; 2) as of FF 45, the test 
sites offered on https://pki.goog using certs from the potentially broken 
chains do not trigger any validation errors, which implies that FF's path 
validation algorithm is not RFC compliant.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Next CA Communication

[Ryan Sleevi via dev-security-policy]

Gerv,

I'm curious whether you would consider 18 months an appropriate target for
a deprecation to 1 year certificates. That is, do you believe a transition
to 1 year certificates requires 24 months or 18 months, or was it chosen
simply for its appeal as a staggered number (1 year -> 2 year certs, 2
years -> 1 year certs)

On Mon, Mar 27, 2017 at 5:10 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 17/03/17 15:30, Gervase Markham wrote:
> > The URL for the draft of the next CA Communication is here:
> > https://mozilla-mozillacaprogram.cs54.force.com/Communications/
> CACommunicationSurveySample?CACommunicationId=a050S00G3K2
> >
> > Note that this is a _draft_ - the form parts will not work, and no CA
> > should attempt to use this URL or the form to send in any responses.
>
> Here is another proposed question:
>
> Certificate Validity Periods
>
> Your attention is drawn to CAB Forum ballot 193, which recently passed.
> This reduces the maximum permissible lifetime of certificates from 39 to
> 27 months, as of 1st March 2018. In addition, it reduces the amount of
> time validation information can be reused, from 39 to 27 months, as of
> 31st March 2017. Please be aware of these deadlines so you can adjust
> your practices accordingly.
>
> Mozilla is interested in, and the CAB Forum continues to discuss, the
> possibility of further reductions in certificate lifetime. We see a
> benefit here in reducing the overall turnover time it takes for an
> improvement in practices or algorithms to make its way through the
> entire WebPKI. Shorter times, carefully managed, also encourage the
> ecosystem towards automation, which is beneficial when quick changes
> need to be made in response to security incidents. Specifically, Mozilla
> is currently considering a reduction to 13 months, effective as of 1st
> March 2019 (2 years from now). Alternatively, several CAs have said that
> the need for contract renegotiation is a significant issue when reducing
> lifetimes, so in order that CAs will only have to do this once rather
> than twice, another option would be to require the reduction from 1st
> March 2018 (1 year from now), the current reduction date.
>
> Please explain whether you would support such a further reduction dated
> to one or both of those dates and, if not, what specifically prevents
> you from lending your support to such a move. You may wish to reference
> the discussion on the CAB Forum public mailing list to familiarise
> yourself with the detailed arguments in favour of certificate lifetime
> reduction.
>
>
> Comments, as always, are welcome.
>
> Gerv
> ___
> 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: Next CA Communication

[Gervase Markham via dev-security-policy]

On 17/03/17 15:30, Gervase Markham wrote:
> The URL for the draft of the next CA Communication is here:
> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2
> 
> Note that this is a _draft_ - the form parts will not work, and no CA
> should attempt to use this URL or the form to send in any responses.

Here is another proposed question:

Certificate Validity Periods

Your attention is drawn to CAB Forum ballot 193, which recently passed.
This reduces the maximum permissible lifetime of certificates from 39 to
27 months, as of 1st March 2018. In addition, it reduces the amount of
time validation information can be reused, from 39 to 27 months, as of
31st March 2017. Please be aware of these deadlines so you can adjust
your practices accordingly.

Mozilla is interested in, and the CAB Forum continues to discuss, the
possibility of further reductions in certificate lifetime. We see a
benefit here in reducing the overall turnover time it takes for an
improvement in practices or algorithms to make its way through the
entire WebPKI. Shorter times, carefully managed, also encourage the
ecosystem towards automation, which is beneficial when quick changes
need to be made in response to security incidents. Specifically, Mozilla
is currently considering a reduction to 13 months, effective as of 1st
March 2019 (2 years from now). Alternatively, several CAs have said that
the need for contract renegotiation is a significant issue when reducing
lifetimes, so in order that CAs will only have to do this once rather
than twice, another option would be to require the reduction from 1st
March 2018 (1 year from now), the current reduction date.

Please explain whether you would support such a further reduction dated
to one or both of those dates and, if not, what specifically prevents
you from lending your support to such a move. You may wish to reference
the discussion on the CAB Forum public mailing list to familiarise
yourself with the detailed arguments in favour of certificate lifetime
reduction.


Comments, as always, are welcome.

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