New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson]

All,
This is just to let everyone know that I posted a new Mozilla Security blog
post this morning. Here is the link>
https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
As I note at the end of the blog post, we continue to seek safeguarding
secure browsing by working with CAs as partners, to foster open and frank
communication, and to be diligent in looking for ways to keep our users
safe.
Thanks,
Ben

[Paul Walsh]

Thanks Ben,

I’ve only had half a cup of coffee this am, so it’s possible I’m not yet awake :)

I have a question about reasons 2 and 3 as they’re closely related to the attack vector.

According to Google, spear phishing attacks have a shelf life of 7 minutes while bulk campaigns have a shelf life of 13 hours. Even if we disbelieve this data and multiple the numbers by 10, we end up with the majority of the harm being done within a week.

Also, if bad actors can automatically acquire a DV cert for any available domain they please, is there actual risk of bad actors waiting for a domain to expire so they can have a valid cert? And they can easily execute a man-in-the-middle attack using a new cert that has a shelf life of 3 months.

All I’ve been working on for years is anti-phishing techniques, so I’m not seeing all of the benefits as some others see them, but perhaps I’m missing something.

I’m talking about the human element of bad actors here, because at the end of the day, it’s all about them and what they will do with expired certs.

If we were talking about EV I’d see every single benefit as described, but not for DV. When I look at our phishing data, the reasons provided for reducing the shelf life of DV outweighs the cost.

There is a cost to website owners. I’d argue it’s an expensive exercise. CAs stand to generate more revenue by shortening the life of a cert, so I don’t know what their motivates could be to fight against this change - aside from wanting to support their customers (website owners). There was no consensus in the CA/Browser Forum - CAs voted against this change.

For those who think I love CAs, my company displaces the need for EV, so I’m certainly not fighting on their behalf. I just don’t see the benefits as browser vendors see them, and there is still no data that I can find, to help me better understand the fine details of points 2 and 3.

I believe browser vendors have the right to enforce what they deem appropriate. I’m simply asking for more details given that you’re engaging with the community.

Thanks,
Paul

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

[Paul Walsh]

Ugh, some poor language/typos but I”m sure people can navigate them. Sorry about that.

> On Jul 9, 2020, at 10:04 AM, Paul Walsh <pa...@metacert.com> wrote:
>
> Thanks Ben,
>
> I’ve only had half a cup of coffee this am, so it’s possible I’m not yet awake :)
>
> I have a question about reasons 2 and 3 as they’re closely related to the attack vector.
>
> According to Google, spear phishing attacks have a shelf life of 7 minutes while bulk campaigns have a shelf life of 13 hours. Even if we disbelieve this data and multiple the numbers by 10, we end up with the majority of the harm being done within a week.
>
> Also, if bad actors can automatically acquire a DV cert for any available domain they please, is there actual risk of bad actors waiting for a domain to expire so they can have a valid cert? And they can easily execute a man-in-the-middle attack using a new cert that has a shelf life of 3 months.
>
> All I’ve been working on for years is anti-phishing techniques, so I’m not seeing all of the benefits as some others see them, but perhaps I’m missing something.
>
> I’m talking about the human element of bad actors here, because at the end of the day, it’s all about them and what they will do with expired certs.
>
> If we were talking about EV I’d see every single benefit as described, but not for DV. When I look at our phishing data, the reasons provided for reducing the shelf life of DV outweighs the cost.
>
> There is a cost to website owners. I’d argue it’s an expensive exercise. CAs stand to generate more revenue by shortening the life of a cert, so I don’t know what their motivates could be to fight against this change - aside from wanting to support their customers (website owners). There was no consensus in the CA/Browser Forum - CAs voted against this change.
>
> For those who think I love CAs, my company displaces the need for EV, so I’m certainly not fighting on their behalf. I just don’t see the benefits as browser vendors see them, and there is still no data that I can find, to help me better understand the fine details of points 2 and 3.
>
> I believe browser vendors have the right to enforce what they deem appropriate. I’m simply asking for more details given that you’re engaging with the community.
>
> Thanks,
> Paul
>
>
>
>
>> On Jul 9, 2020, at 8:46 AM, Ben Wilson via dev-security-policy <dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>> wrote:
>>
>> All,
>> This is just to let everyone know that I posted a new Mozilla Security blog
>> post this morning. Here is the link>

>> https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/ <https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/>

[Ryan Sleevi]

On Thu, Jul 9, 2020 at 1:04 PM Paul Walsh via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> According to Google, spear phishing

I didn't see phishing mentioned in Mozilla's post, which is unsurprising,
since certificates have nothing to do with phishing. Did I overlook
something saying it was about phishing?

It seems reasonable to read it as it was written, which doesn't mention
phishing, which isn't surprising, because certificates have never been able
to address phishing.

[Paul Walsh]

Good question. And I can see why you might ask that question.

The community lead of PhishTank mistakenly said that submissions should only be made for URLs that are used to steal' credentials. This helps to demonstrate a misconception. While this might have been ok in the past, it’s not today.

Phishing is a social engineering technique, used to trick consumers into trusting URLs / websites so they can do bad things - including but not limited to, man-in-the-middle attacks. Mozilla references this attack vector as one of the main reasons for wanting to reduce the life of a cert. They didn’t call it “phishing” but that’s precisely what it is.

We can remove all of my references to “phishing” and replace it with “security risks” or “social engineering” if it makes this conversation a little easier.

And, according to every single security company in the world that focuses on this problem, certificates are absolutely used by bad actors - if only to make sure they don’t see a “Not Secure” warning.

I’m not talking about EV or identity related info here as it’s not related. I’m talking about the risk of a bad actor caring to use a cert that was issued to someone else when all they have to do is get a new one for free.

I don’t see the risk that some people see. Hoping to be corrected because the alternative is that browsers are about to make life harder and more expensive for website owners with little to no upside - outside that of a researchers lab.

Warmest regards,
Paul


> On Jul 9, 2020, at 11:26 AM, Ryan Sleevi <ry...@sleevi.com> wrote:

[Ben Wilson]

Thanks, Paul, for your comments and concerns regarding our reasons 2 and 3,
and the costs vs. benefits of going to a 398-day certificate lifetime.
We'll keep those in mind as we move forward. In response, the security of
our users is the primary concern for Mozilla. So while we recognize there
might be added costs and burdens, we still believe that they do not
outweigh the user security benefits of moving to a 398-day certificate
lifetime.
Thanks again,
Ben

[Ryan Sleevi]

I’m not sure how that answered my question? Nothing about the post seems to
be about phishing, which is not surprising, since certificates have nothing
to do with phishing, but your response just talks more about phishing.

It seems you may be misinterpreting “security risks” as “phishing“, since
you state they’re interchangeable. Just like Firefox’s sandbox isn’t about
phishing, nor is the same-origin policy about phishing, nor is Rust’s
memory safety about phishing, it seems like certificate security is also
completely unrelated to phishing, and the “security risks” unrelated to
phishing.

[Paul Walsh]

Ryan,

If you said “Mozilla is making this change and there’s nothing you can say or do to change that” I would accept those words, as I did with Ben’s response. But you engaged after Ben’s response, so I’d like to respond to your comments.

Here’s some common ground… we both believe that there are security implications that are NOT related to phishing. BOOM! We agree on something.

Dear Mozilla, and this wonderful community, I’m not debating this change. I accept it is happening irrespective of what other stakeholders might think. I am simply responding to Ryan’s comments :-))

Back to Ryan…

Mozilla provides 3 reasons for its decision.

"1. Agility”

No comment. I will defer to the people who know way more than me.

There are lots of people who know more than me on the subject of phishing-related security risks too and I learn from them. But it’s an area in which I have an extremely deep understanding and appreciation for so it might be a good idea to try to understand where I’m coming from. It’s pretty much all I work on every day.

Phishing is all about how humans interact with URIs and web documents based on whatever UI they use. If there’s dedicated UI that provides additional context for URIs and web documents, that too will impact their actions.

My research into UI and metadata for providing additional context for URIs started before I co-founded the first ever W3C Incubator Activity (with Phil Archer from) - to create a new method of URL Classification and Content Labeling, which later replaced PICS as a Full Recomendation in 2009. The W3C Mobile Web Initiative was going to mandate compliance with best practices using the outcome of this initiative (a trustmark in the form of metadata) - coincidentally, I was one of the original seven founders of the W3C MWI and was on the Steering Council for the first year. I digress with a humblebrag because I don’t have the Google or Mozilla brand behind me to automatically assert credibility.

Here’s one of the first browser extensions that provided additional UI for URIs, to help make the web easier to navigate for people with accessibility considerations as well as security and privacy related information: https://www.w3.org/2001/sw/sweo/public/UseCases/Segala/ <https://www.w3.org/2001/sw/sweo/public/UseCases/Segala/> I was the founder and CEO of Segala.

(For anyone who’s moderately interested in phishing, please look up “reverse-proxy phishing” as it will scare the pants off you.)

So…

"2. Limit exposure to compromise"

Keys valid for longer than one year have greater exposure to compromise, and a compromised key could enable an attacker to intercept secure communications and/or ***impersonate a website*** until the TLS certificate expires.”

“Impersonate a website” = phishing. This is a security risk. “Security risk” and “phishing” are not interchangeable and I never said they were. It’s preferable that you don’t quote me with words that I didn’t use.

"3. TLS Certificates Outliving Domain Ownership"

TLS certificates provide authentication, meaning that you can be sure that you are sending information to the correct server and ***not to an imposter trying to steal your information***."

“Imposter” on the Internet = phishing.

"If the owner of the domain changes or the cloud service provider changes, the holder of the TLS certificate’s private key (e.g. the previous owner of the domain or the previous cloud service provider) ***can impersonate the website*** until that TLS certificate expires."

“can impersonate the website” = you guessed what I’m about to say… “PHISHING”.

It doesn’t matter if you don’t call this phishing, in the same way that it doesn’t matter if you don’t call the things that are used to reduce the risk of pedestrians being hit by speeding traffic, “speed bumps”. You could argue that they’re not called “speed bumps” but are in fact, called “speed breakers” - but they all refer to the same thing. So, even if you personally don’t call this phishing, it is phishing in the eyes of the security world and every single phishing expert in the universe.

I had to encourage the MWI team not to redefine the meaning of “webpage” because everyone just knew what it was. There’s no point in taking about documents and URIs to consumers. So rather than teach them the real words, we should talk to them in the language they understand.

Separately...

I previously ignored the fact that the post says “you can be sure that you are sending information to the correct server and not to an imposter trying to steal your information”, because I didn’t want an EV conversation to take away from the above. I’ll bring it up now for the sake of the record though.

If “you can be sure" refers to ‘consumers', this statement is fundamentally wrong because it does not reference EV. If it’s not referring to consumers, who is it referring to and in what context? It’s a very strange sentence that could have different meanings. I suggest an edit to be more clear and concise.

Now that I have proven beyond a shadow of a doubt that we are talking about phishing, feel free to debate the merits of my points raised in my original email.

Regards,

Paul





> On Jul 9, 2020, at 3:35 PM, Ryan Sleevi <ry...@sleevi.com> wrote:
>
> I’m not sure how that answered my question? Nothing about the post seems to be about phishing, which is not surprising, since certificates have nothing to do with phishing, but your response just talks more about phishing.
>
> It seems you may be misinterpreting “security risks” as “phishing“, since you state they’re interchangeable. Just like Firefox’s sandbox isn’t about phishing, nor is the same-origin policy about phishing, nor is Rust’s memory safety about phishing, it seems like certificate security is also completely unrelated to phishing, and the “security risks” unrelated to phishing.
>

> On Thu, Jul 9, 2020 at 2:48 PM Paul Walsh <pa...@metacert.com <mailto:pa...@metacert.com>> wrote:
> Good question. And I can see why you might ask that question.
>
> The community lead of PhishTank mistakenly said that submissions should only be made for URLs that are used to steal' credentials. This helps to demonstrate a misconception. While this might have been ok in the past, it’s not today.
>
> Phishing is a social engineering technique, used to trick consumers into trusting URLs / websites so they can do bad things - including but not limited to, man-in-the-middle attacks. Mozilla references this attack vector as one of the main reasons for wanting to reduce the life of a cert. They didn’t call it “phishing” but that’s precisely what it is.
>
> We can remove all of my references to “phishing” and replace it with “security risks” or “social engineering” if it makes this conversation a little easier.
>
> And, according to every single security company in the world that focuses on this problem, certificates are absolutely used by bad actors - if only to make sure they don’t see a “Not Secure” warning.
>
> I’m not talking about EV or identity related info here as it’s not related. I’m talking about the risk of a bad actor caring to use a cert that was issued to someone else when all they have to do is get a new one for free.
>
> I don’t see the risk that some people see. Hoping to be corrected because the alternative is that browsers are about to make life harder and more expensive for website owners with little to no upside - outside that of a researchers lab.
>
> Warmest regards,
> Paul
>
>

>> On Jul 9, 2020, at 11:26 AM, Ryan Sleevi <ry...@sleevi.com <mailto:ry...@sleevi.com>> wrote:

[Ryan Sleevi]

>
> Now that I have proven beyond a shadow of a doubt that we are talking
> about phishing, feel free to debate the merits of my points raised in my
> original email.
>

Thanks Paul. I think you're the only person I've encountered who refers to
key compromise as phishing, but I don't think we'll make much progress when
words have no meaning and phishing is used to describe everything from
"monster in the middle" to "cache poisoning".

Since, to use the same analogy, everything from speed limits and signs to
red light cameras to speed traps to roundabouts is being called "speed
bumps", it's not worth engaging further.

[Eric Mill]

Just to depersonalize it a bit so it's not only Ryan responding - what Ryan
is saying is correct. Mozilla's blog post uses the phrase "impersonating a
website" to describe non-phishing attacks, such as performing active MITM
attacks that modify or replace (or surveil) data in flight, or relying on
cached DNS data from a domain which recently changed hands to otherwise get
"in front" of the connection to the authorized website. This is
impersonation in the more narrow, technical sense of having subverted
technical assurance guarantees that cause a user's client software to be
unable to realize they're not talking to the intended destination -- not in
the sense of impersonating a hostname or organization to deceive humans.

In other words, neither of those are phishing attacks. Phishing isn't
really relevant to this discussion at all, so it would be better to focus
the discussion on the security improvements that Mozilla cites in their
post, which relate to mitigating damage from key compromise, improving the
web's agility in replacing old or compromised ciphers/protocols/techniques,
and giving domain owners stronger assurance over the security of
connections to the domains they acquire.

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

--
Eric Mill
617-314-0966 | konklone.com | @konklone <https://twitter.com/konklone>

[Ben Wilson]

Some people have asked whether two-year certificates existing on August 31
would remain valid. The answer is yes. Those certificates will remain
valid until they expire. The change only applies to certificates issued on
or after Sept. 1, 2020.

[Doug Beattie]

Ben,

For the avoidance of doubt, I assume this means Sept 1, 00:00 UTC.

[Ben Wilson]

Yes, that's right.

On Fri, Jul 10, 2020 at 12:11 PM Doug Beattie <doug.b...@globalsign.com>
wrote:

[Matt Palmer]

On Fri, Jul 10, 2020 at 10:48:39AM -0600, Ben Wilson via dev-security-policy wrote:
> Some people have asked whether two-year certificates existing on August 31
> would remain valid. The answer is yes. Those certificates will remain
> valid until they expire. The change only applies to certificates issued on
> or after Sept. 1, 2020.

A histogram of the number of certificates grouped by their notBefore date is
going to show a heck of a bump on August 31, I'll wager. Will be
interesting to correlate notBefore with SCTs.

- Matt

[Nick Lamb]

On Sat, 11 Jul 2020 11:06:56 +1000
Matt Palmer via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:
> A histogram of the number of certificates grouped by their notBefore
> date is going to show a heck of a bump on August 31, I'll wager.
> Will be interesting to correlate notBefore with SCTs.

I expect there will be a modest number of entities which are all three
of:

1. Aware this is happening in time to obtain certificates on or before
August 31

2. Sufficiently unprepared for shorter certificate lifetimes still
that they desire a longer lived certificate rather than just using new
one year certificates (or automation).

3. And also organised enough to execute on a plan which obtains
certificates in a timely fashion.

But, there's no particular attraction to August 31 itself for these
subscribers, once they meet these criteria why shouldn't they take
action sooner? So I'd expect this bump to be quite small and also
spread over days and weeks.

For the subscribers who are too late, too bad. I'm sure from September
for the next year or two commercial CAs will see some level of whining
from disgruntled customers whose cheese has been moved and aren't happy
about it. Some of it might leak here too.

I don't anticipate a WoSign-style back-dating epidemic. The benefits to
the subscriber are relatively small and the risk to a CA that gets
caught is more obvious than ever.


Nick.

[Christian Felsing]

Am 09.07.2020 um 17:46 schrieb Ben Wilson via dev-security-policy:
> https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/

Hi,

blog post should clarify if this is valid for certificates issued by
preinstalled root CAs only or also for CAs installed by user.


regards
Christian

[Ben Wilson]

Hi Christian,
I think your concern is about how our code will enforce this. Because our
policy only applies to roots that are built in, our intent is to have our
code apply this restriction only to certificates that chain up to built-in
roots.
Thanks,
Ben

[None Of]

Hello Ben,

I also would like clarification as to whether this change is an "administrative change" for Mozilla accepting CAs in the included root store, or whether it will be a technical change in how Firefox validates CA certificate validity.

If users install a CA cert that has a validity longer than 398 days after 1 Sept 2020, will this cause warning messages to appear?

[Ben Wilson]

Dear Steven,
CA certificates can have a validity longer than 398 days. The policy
applies to the validity period of TLS server certificates. At the CA level,
it will be enforced as a compliance issue in the root store when we accept
or remove a root CA in the "publicly trusted" root store. It will also be
enforced at the server-certificate level, through the incident-reporting
process and treated as a mis-issuance. See
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#24-incidents.
However, if a user installs its own CA certificate, then that CA can issue
server certificates with validity longer than 398 days. The code will check
the TLS server certificate to see if it chains to a publicly trusted root
and whether it was issued on or after 1-Sept-2020. If so, then if it does
not have a lifetime of less than 398 days, the TLS connection will be
blocked and there will be a warning message. See
https://bugzilla.mozilla.org/show_bug.cgi?id=908125
Does that answer your question?
Thanks,
Ben

On Tue, Aug 25, 2020 at 10:42 AM None Of via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Tuesday, July 14, 2020 at 2:13:30 PM UTC-4, Ben Wilson wrote:

> Hello Ben,
>
> I also would like clarification as to whether this change is an
> "administrative change" for Mozilla accepting CAs in the included root
> store, or whether it will be a technical change in how Firefox validates CA
> certificate validity.
>
> If users install a CA cert that has a validity longer than 398 days after
> 1 Sept 2020, will this cause warning messages to appear?