Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Open Source CA Software
316 views
Skip to first unread message
James Burton
Mar 14, 2019, 6:54:52 PM3/14/19
to mozilla-dev-security-policy
Let's Encrypt CA software 'Boulder' is open source for everyone to browse
and check for issues. All other CAs should follow the Let's Encrypt lead
and open source their own CA software for everyone to browse and check for
issues. We might have found the serial number issue sooner.
Thank you,
Burton
and check for issues. All other CAs should follow the Let's Encrypt lead
and open source their own CA software for everyone to browse and check for
issues. We might have found the serial number issue sooner.
Thank you,
Burton
Ryan Sleevi
Mar 14, 2019, 6:57:22 PM3/14/19
to James Burton, mozilla-dev-security-policy
logically follow.
James Burton
Mar 14, 2019, 7:35:53 PM3/14/19
to Ryan Sleevi, mozilla-dev-security-policy
(Forgot to post it to m.d.s.p)
Your right that we all failed to conduct the proper due diligence source
code checks on EJBCA and therefore missed this important issue. We all need
to learn from this past mistake and implement better checks which prevents
issues like this that might arise in the future.
Thank you,
Burton
Your right that we all failed to conduct the proper due diligence source
code checks on EJBCA and therefore missed this important issue. We all need
to learn from this past mistake and implement better checks which prevents
issues like this that might arise in the future.
Thank you,
Burton
Tomas Gustavsson
Mar 15, 2019, 4:42:56 AM3/15/19
to mozilla-dev-s...@lists.mozilla.org
Hi,
It might have been found, but there's a good chance it would have been bypassed anyhow. Since it was not a bug in the code, you would have to had analyzed it in the context of the discussions around b164, which I think there are probably very few people who could/would. I may be wrong, and we surely appreciate the more eyes on EJBCA the better. We love issue reports from the Community.
My take is that this was a bit of pure chance at play here. As EJBCA had used 8 octets serial numbers (64 bits) as default since 2001, and by coincidence CAB Forum chose exactly the same number, 64 bits (note that I speak only about the number itself here, not about the meaning). Simply by the similarity of those numbers it was overlooked that dragons were lurking. If CAB Forum had chosen 56, 72, 96 or any other random number, nobody would have missed it and compliant configurations would have been made.
Generally, as you know, EJBCA has a wide array of use cases where CAB
Forum is one important, but must remain configurable (down to 4 octets serials as example). An important user base as CAB Forum deserves compliant defaults of course, which has now been addressed by Mike and his team.
Here's hoping for more code reviews!
Cheers,
Tomas
It might have been found, but there's a good chance it would have been bypassed anyhow. Since it was not a bug in the code, you would have to had analyzed it in the context of the discussions around b164, which I think there are probably very few people who could/would. I may be wrong, and we surely appreciate the more eyes on EJBCA the better. We love issue reports from the Community.
My take is that this was a bit of pure chance at play here. As EJBCA had used 8 octets serial numbers (64 bits) as default since 2001, and by coincidence CAB Forum chose exactly the same number, 64 bits (note that I speak only about the number itself here, not about the meaning). Simply by the similarity of those numbers it was overlooked that dragons were lurking. If CAB Forum had chosen 56, 72, 96 or any other random number, nobody would have missed it and compliant configurations would have been made.
Generally, as you know, EJBCA has a wide array of use cases where CAB
Forum is one important, but must remain configurable (down to 4 octets serials as example). An important user base as CAB Forum deserves compliant defaults of course, which has now been addressed by Mike and his team.
Here's hoping for more code reviews!
Cheers,
Tomas
Mike Kushner
Mar 15, 2019, 10:59:38 AM3/15/19
to mozilla-dev-s...@lists.mozilla.org
I will add though, and stress, that this was not an issue with how EJBCA generates serial numbers. EJBCA still produces serial numbers with the max entropy for a given serial number length, as configured in number of octets. If you set EJBCA to use 20 octets you'll get 159 bits of entropy, the max available without breaking the RFC, and it's been that way since 2014.
To save people time, by the way, here you go:
https://svn.cesecore.eu/svn/ejbca/trunk/ejbca/modules/cesecore-common/src/org/cesecore/certificates/ca/internal/SernoGeneratorRandom.java
This was not an issue with the source, it was an issue with the end user's understanding of what it means to define an SN length as given number of of octets, how integer octets are defined in x690, and what entropy that can be derived. That is all a documentation failure on our end - we could have been more explicit, and we could have reached out more.
There's also the faulty assumption that SN length = entropy. As we've seen, many other CA implementations produce SNs with far less entropy than their length would allow. I'm not saying that there's anything inherently wrong with that, but it illustrates the danger of making assumptions.
As we didn't follow cabf at the time we weren't fully aware of the severity of the problem, and assumed that affected parties understood their configurations and raised the SN length.
Matthew Hardeman
Mar 15, 2019, 11:28:15 AM3/15/19
to Mike Kushner, mozilla-dev-security-policy
I think open source is great, but it's not a panacea.
While there are many CAs and several root programs, this community is a
relatively small one in the grand scheme.
Prior events suggest that there are not enough people with the necessary
skill overlap to parse both the rules and the code to make useful analysis
while also having an interest in doing so.
On Fri, Mar 15, 2019 at 9:59 AM Mike Kushner via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> On Thursday, March 14, 2019 at 11:54:52 PM UTC+1, James Burton wrote:
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
While there are many CAs and several root programs, this community is a
relatively small one in the grand scheme.
Prior events suggest that there are not enough people with the necessary
skill overlap to parse both the rules and the code to make useful analysis
while also having an interest in doing so.
On Fri, Mar 15, 2019 at 9:59 AM Mike Kushner via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> On Thursday, March 14, 2019 at 11:54:52 PM UTC+1, James Burton wrote:
> Dude, EJBCA has been open source long enough to be able to legally vote
> and have a driver's license. Literally. But I agree, and we are open source
> for exactly that reason.
>
> I will add though, and stress, that this was not an issue with how EJBCA
> generates serial numbers. EJBCA still produces serial numbers with the max
> entropy for a given serial number length, as configured in number of
> octets. If you set EJBCA to use 20 octets you'll get 159 bits of entropy,
> the max available without breaking the RFC, and it's been that way since
> 2014.
>
> To save people time, by the way, here you go:
>
> https://svn.cesecore.eu/svn/ejbca/trunk/ejbca/modules/cesecore-common/src/org/cesecore/certificates/ca/internal/SernoGeneratorRandom.java
>
> This was not an issue with the source, it was an issue with the end user's
> understanding of what it means to define an SN length as given number of of
> octets, how integer octets are defined in x690, and what entropy that can
> be derived. That is all a documentation failure on our end - we could have
> been more explicit, and we could have reached out more.
>
> There's also the faulty assumption that SN length = entropy. As we've
> seen, many other CA implementations produce SNs with far less entropy than
> their length would allow. I'm not saying that there's anything inherently
> wrong with that, but it illustrates the danger of making assumptions.
>
> As we didn't follow cabf at the time we weren't fully aware of the
> severity of the problem, and assumed that affected parties understood their
> configurations and raised the SN length.
> _______________________________________________
> and have a driver's license. Literally. But I agree, and we are open source
> for exactly that reason.
>
> I will add though, and stress, that this was not an issue with how EJBCA
> generates serial numbers. EJBCA still produces serial numbers with the max
> entropy for a given serial number length, as configured in number of
> octets. If you set EJBCA to use 20 octets you'll get 159 bits of entropy,
> the max available without breaking the RFC, and it's been that way since
> 2014.
>
> To save people time, by the way, here you go:
>
> https://svn.cesecore.eu/svn/ejbca/trunk/ejbca/modules/cesecore-common/src/org/cesecore/certificates/ca/internal/SernoGeneratorRandom.java
>
> This was not an issue with the source, it was an issue with the end user's
> understanding of what it means to define an SN length as given number of of
> octets, how integer octets are defined in x690, and what entropy that can
> be derived. That is all a documentation failure on our end - we could have
> been more explicit, and we could have reached out more.
>
> There's also the faulty assumption that SN length = entropy. As we've
> seen, many other CA implementations produce SNs with far less entropy than
> their length would allow. I'm not saying that there's anything inherently
> wrong with that, but it illustrates the danger of making assumptions.
>
> As we didn't follow cabf at the time we weren't fully aware of the
> severity of the problem, and assumed that affected parties understood their
> configurations and raised the SN length.
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
0 new messages