
Actalis: Insufficient Serial Number Entropy - y0ghur7_xxx
https://bugzilla.mozilla.org/show_bug.cgi?id=1534295
======
nicolast
Cases like this seem to confirm the approach LetsEncrypt took of only issuing
certificates of a somewhat-short lifetime, which kind-of forces a user to
fully automate the handling of certificates (monitoring expiration, taking
measures to request a new cert in time, deploying the new cert,...).

The practice of issuing certificates with a (sometimes very) long lifetime,
from one year and up, results in a situation where such automation is not
strictly required, and complex bureaucratic processes can be put in place to
replace certs, which becomes a major issue when 'emergency' revocations are
necessary. I'd argue such bureaucratic processes don't even increase
'security', because in the end they rely on people performing manual
operations (often with more rights granted than strictly required), whilst an
automated system can be more easily vetted, tested, and locked down.

------
kevingadd
Aside from the necessity of enforcing good security policy here, it's brutal
to observe the situation Actalis was stuck in based on the thread's ongoing
comments. They clearly got themselves into bad/unsustainable deals with big
customers where they made promises that couldn't be fulfilled in these
circumstances, so their choices were to (likely) lose those customers + harm
their customers' users, or to risk getting kicked out of the root program. And
if they don't play their cards right it's possible they BOTH lose their
customers and get booted out of the root program eventually anyway. Not a fun
situation to be in, especially because in this case it sounds like they got
screwed by a bug in third-party software and not specifically due to bad
internal processes.

~~~
mghilardi
I think Actalis found itself between a very hard rock and an even harder
place. I am italian and I have worked with some public entities similar to the
ones Actalis provided certificates to. There is a private network "SPC" of
public italian organizations, with many machine-to-machine HTTPS web services
that MUST by law provide updates to the central government with quite strict
deadlines.

On such networks, certificate pinning is very common and possibly even
recommended, contrary to the "Basic Requirements" and recommendations of CAs.

Failing to respect such deadlines causes penalties to the local governments,
and in grave cases may even be a crime: "public service interruption" which
would initiate a trial, with more fines and possibly jail time.

Thus Actalis had to choose between:

1\. follow the CAs "Basic Requirements" that force CAs to quickly revoke
certificates when a problem is discovered. Then most of the certificates would
be revoked _before_ the public customers managed to replace them - disrupting
their operativity, risking penalties for the missed deadlines and possibly
trial and jail time for "public service interruption". To avoid this, they
would then need to demonstrate in a public trial that the public customers
were well informed that certificates could be revoked and re-issued at any
time with very short warning time, and they did everything they could to avoid
the "public service interruption", both pre-emptively (when negotiating the
sell of certificates and educating the customers) and re-actively (when the
serial numbers vulnerability was discovered). Quite a hard path.

2\. contact the customers, push them to quickly replace the compromised
certificates, and revoke them only _afterwards_ , thus avoiding service
disruptions.

They chose 2. Unluckily italian public organizations are _very_ slow, which in
the end caused Actalis to miss their BR deadlines by a long shot.

~~~
carapace
Thank you! Reading between the lines it seemed clear that just revoking the
certs would have caused major infrastructure problems, but what you describe
sounds severe. No wonder they chose to take the hit in BR deadlines!

------
obituary_latte
I kind of feel for Actalis. It seems like they were caught between a rock and
a hard place seeing as their customers were not/could not respond as quickly
as hoped and revoking the certs could negatively impact end-users by
preventing them from for example obtaining prescriptions etc. The language is
dense for me but it also sounded like there was a reasonable explanation in
the BR for the exception (paraphrasing: ‘negatively impacting a large swath of
internet users’) but it didn’t seem to assuage the concern of Ryan. I hope the
Actalis guy didn’t lose his job.

~~~
bjpbakker
From the thread is becomes painfully clear how horrible Actalis is set up to
act as a CA. Instead it seems they chose to break the BR by default. Almost 5
months to reissue a little over 250k certificates is not what you may expect
from a CA that a major browser should trust.

The argument that there might be some end-users unable to renew their
prescription seems mostly used to gain sympathy. Also this will most probably
not be “a large swath of internet users”.

I do hope Actalis step up their game and regain some trust. Or it may become
the next symantec.

~~~
michaelt
On the other hand, as far as I can tell:

* The baseline requirement is 64 bits of entropy and Actalis were providing 63 bits, i.e. only short by a single bit. It would seem unusual if the baseline requirements were a mere one bit of entropy from insecurity.

* The requirement for 64 bits of entropy is to reduce the risk of hash collision attacks [1] - which have only ever been demonstrated for MD5 and SHA-1, neither of which are used to sign certificates any more.

If web security was a tightrope, this would be like hearing that the _second_
safety net, _underneath_ the first believed-to-be-robust safety net, was found
to be strong enough to catch a 900 lbs person, when it was specified for 1000
lbs.

[1]
[https://cabforum.org/2016/03/31/ballot-164/](https://cabforum.org/2016/03/31/ballot-164/)

------
y0ghur7_xxx
Actalis is a major Italian CA that works mainly with big banks and the public
sector, like (from the bug report)

\- the Tuscany Region (e.g. O=Rete Telematica Regionale Toscana, etc.)

\- the Piedmont Region (e.g. O=CSI Piemonte, etc.)

\- central public government (eg. O=Bank of Italy, Ministry of Transports,
etc.)

\- major banks (e.g. O=Unicredit S.p.A., FinecoBank, etc.)

\- large private companies (e.g. O=SNAM, Terna, Wind, etc.)

\- chambers of commerce

------
londons_explore
On one hand, this incident was a massive amount of work by probably thousands
of people to replace all the revoked certificates. Certificates which are
perfectly good for communication and do not pose any significant security
risk.

On the other hand, allowing a CA to violate the BR's without pain will just
encourage others to do so.

~~~
y0ghur7_xxx
> Certificates which are perfectly good for communication and do not pose any
> significant security risk.

Is it so? I remember that in 2008 someone was able to create a rouge CA
certificate because of the predictability of serial numbers[1]. It was a
different time: we still used md5, but are you sure the limited entropy used
to generate serial numbers does not pose any security risk?

[1][https://www.win.tue.nl/hashclash/rogue-
ca/](https://www.win.tue.nl/hashclash/rogue-ca/)

~~~
tialaramex
The difference here is one bit. The BRs say you must use at least 64-bits of
entropy, EJBCA out of the box used 63-bits. A bad guy might need to spend say
$40 trillion to make a bogus cert instead of $80 trillion. No bad guys have
$40 trillion so it's irrelevant. And that would be if we were still using
SHA-1 (which is broken, and so the entropy is all that would keep you safe
against collision attacks) but in fact Actalis and other CAs are only issuing
with SHA-256 which isn't broken.

This is a Brown M&M ‡. It doesn't actually matter in terms of security,
63-bits, 65-bits, it's never going to make a real difference. But we wrote
64-bits in those rules, if we can't trust you to obey that rule, who says you
got the really important parts right?

‡ [https://www.snopes.com/fact-check/brown-out/](https://www.snopes.com/fact-
check/brown-out/)

~~~
wereHamster
It's not that Actalis has not tried to obey, or purposefully withheld
information or tried to mislead the community. The disagreement is on how
strict the interpretation of the BR should be.

Would Van Halen abort a concert if there was a single brown M&M in a bowl of
1000? Probably not because even though it's a violation of their contract,
they got their point across, it still means the organisers had read through
the full contract and tried to obey.

Reading through the discussion, I wish I could be as strict as Ryan Sleevi is
in demanding that browsers fix their incompatibilities with the web's BR
(ehm.. standards). Chrome, there's this bug where this element is placed one
pixel off from where it should be (it's by no means critical and does not
impact users of any website in any meaningful way, but according to the CSS
Box Model Module Level 3 spec, paragraph suchandsuch it's wrong). How about
you fix it by next week or I'll uninstall you from all systems on the world.

------
Dayshine
Could somebody explain to me why Mozilla (or whatever organisation is using
bugzilla here) are in a position to dictate policy here?

If the majority of outstanding certificates were held by the Italian
government, major banks and hospitals, what are the CA supposed to do if
they're just told "No, you won't revoke the certificates until we're ready, we
don't think the risk is worth it"? Further, reading a comment below on the
usage of these certificates by the Italian state for mandatory reporting: it
sounds like revoking could be considered a criminal offense...

This very much reads like a private entity mandating that tens if not hundreds
of thousands of Euros are spent by the Italian state over a very minor
security risk.

~~~
tialaramex
Somebody has to decide who is trusted. Mozilla (a not-for-profit) thinks that
it suits their mission best if they're deciding, at least when it comes to
their browser, Firefox, by default.

If you think somebody else should decide - maybe the Government of Italy, or
the Queen of England, or Donald Trump, or you personally, then here's a few
questions for your new Root Trust Programme:

1\. Why? At least Mozilla's rationale is related to a fact, they make Firefox,
so it trusts whatever they decide, what would be the rationale for why the
Pope gets to decide?

2\. Are they actually doing it? This is largely a tedious responsibility. But,
if you decide to slack off, every Firefox user gets screwed. So, you know,
you're going to need to put those hours in. Forever. I've lost count of how
many people or organisations decided they could do better and didn't last a
year.

3\. Where's the transparency? The main way Mozilla stands out from the other
big trust store operators (Apple, Microsoft, Google, and arguably Oracle) is
that they're a not-for-profit and so they operate transparently. Your
contributions are welcome at m.d.s.policy
[https://groups.google.com/forum/#!forum/mozilla.dev.security...](https://groups.google.com/forum/#!forum/mozilla.dev.security.policy)
where we are currently discussing the minutiae of Certificate Policy
documentation. If your alternative is less transparent, how is that not worse?

~~~
Dayshine
I'm not saying Mozilla isn't a good organisation to run this, I'm saying it
seems insane to have what seems like policies that don't allow for any
proportional response.

I don't know how involved you are, but to a lay observer this story seems like
Mozilla's policies are entirely black and white, to the benefit of nobody
(except perhaps to reduce work I suppose, which is reasonable, but not really
a valid reason in terms of security)

Is there no tiered approach to risks? Hell, in this situation it seems like
more harm and risk will have been created by the rush to reissue certificates
that would have been caused by this theoretical security vulnerability.

Edit: Actually, on further reading, it seems like the issue is more that
Actalis didn't correctly invoke their right to this discretionary power?

~~~
sleevi
You may also enjoy
[https://wiki.mozilla.org/CA/Incident_Dashboard](https://wiki.mozilla.org/CA/Incident_Dashboard)
, which all the CAs responding to such incidents need to be aware of, and
which shows that there is a rather large amount of proportionality, based on
an appropriate degree of transparency and communication.

~~~
Dayshine
That is very interesting, thank you. And yes, the tone and approach in all the
incidents I read through there seemed great.

------
hannob
For context: This issue affected a large number of CAs because it was an issue
in a widely used free CA operation software (EJBCA).

------
zaarn
What surprises me is that people want OV certificates, since to my knowledge
they are no different to DV certs in all applications...

~~~
Maxious
Sounds like a good insurance policy where your CA will risk their root program
participation, and the managers their jobs to keep your certificates unrevoked
for months:

> we have met a lot of resistances and compliances from the enterprise
> customers, mainly public entities, to whom we have wrongly responded by
> giving more time. Four months to replace some certificates is more than
> enough.

> As managing director I have just decided some organization and role changes
> with immediate effect: I have removed the SSL infrastructure and Operation
> managers

