We had been invited to spend time with the open source community in China
by one of the developers - Paul Yang - who
participates in the OpenSSL project. A number of the team members had
communicated via email over the last year and when the suggestion was made
there were enough of us willing and interested to visit China for a “tour”
to make sense. So the tour was agreed as a good thing and that started
the journey that lead to spending a week in China (last week as I write
this on the plane on the way back to Australia).
Over the past few years we’ve come to the realisation that there is a surprising
(to us) amount of interest in OpenSSL in China. That shouldn’t have been a surprise
as China is a huge technologically advanced country, but now we know better thanks
to correspondence with many new Chinese contacts and the receipt of significant
support from multiple Chinese donors (most notably from Smartisan.
We have accepted an invitation from BaishanCloud to
visit China in person and meet with interested OpenSSL users and stakeholders in September.
We’d like to thank BaishanCloud for hosting us and Paul Yang and his colleagues there
for the substantial amount of work that went into arranging this trip.
We’ve had a change in the stakeholder aspect of this new FIPS 140 validation effort.
The original sponsor, SafeLogic, with whom we jump-started
this effort a year ago and who has worked with us since then, is taking a well-deserved
bow due to a change in circumstances. Supporting this effort has been quite a strain for
a relatively small company, but SafeLogic has left us in a fairly good position. Without
SafeLogic we wouldn’t have made it this far, and while I don’t anticipate any future
SafeLogic involvement with this effort from this point on, I remain enormously grateful
to SafeLogic and CEO Ray Potter for taking on such a bold and ambitious venture.
It’s been almost a year since plans for a new FIPS 140 validation were
first announced.
Several factors have led to this long delay. For one, we chose to focus
our limited manpower resources on higher priority objectives such as the
TLS 1.3 implementation. SafeLogic has also experienced difficulties in
obtaining the funding for their intended sponsorship; potential sponsors can
contact them directly.
With TLS 1.3 now done (pending only a final TLS 1.3 specification) we’re
now in a position to turn our attention to the new FIPS module, and just
in the nick of time Oracle has pledged enough funding to get us off to a
good start. With financial support from the Linux Foundation Core
Infrastructure Initiative temporarily interrupted, leaving a team member with
no income, that funding eases the pressure to seek new long term employment.
The following is a press release that we just released, with the cooperation
and financial support of the Core Infrastructure Initiative and the
Linux Foundation.
In the next few days we’ll start sending out email to all contributors
asking them to approve the change. In the meantime, you can visit
the licensing website and search for
your name and request the email. If you have changed email addresses,
or want to raise other issues about the license change, please email
license@openssl.org. You can also post
general issues to
openssl-users@openssl.org.
We are grateful to all the contributors who have contributed to OpenSSL
and look forward to their help and support in this effort.
The official press release can be found at the CII website. The rest of this post is a copy:
Last October, the OpenSSL Project team had a face to face meeting.
We talked about many topics but one of them was that, in recent years, we have
seen much more involvement from the community and that we would like to
encourage that further. For example, there are a number of people in the
community who we know and trust. We would like those people to get involved more
and make it easier for them to contribute. We decided to introduce the
concept of a “committer” (borrowed from the Apache concept): someone who has the
ability to commit code to our source code repository but without necessarily
having to become a full team member. This might be seen as a stepping-stone for
someone who aspires to full team membership, or simply as an easier way of
contributing for those that don’t. Those people could help with our review
process (i.e., their reviews would count towards approval) - which might help us
keep on top of the github issues and pull request queues.
The audit took place during 2015 in two phases while the OpenSSL project was
working on the development of the (now released) 1.1.0 version. We chose to
audit the “master” branch of the code as it stood at the time. OpenSSL 1.1.0 has
made some extensive internal changes, most notably in libssl with the new
state machine code, as well as the new packet parsing code. We wanted the audit
team to review that code to give us confidence that what we were delivering was
sound.
I think the most important news here, is that our next release will
include TLS 1.3. Our current plan is that this will be 1.1.1, which means
that it is API-compatible with the current 1.1.0 release. This is really
only possible because of the work we did on making most of the structure
internals opaque. Also, since we are doing all of our work in public on
our GitHub repository, we hope that the entire community will be able to
“follow along at home” and help us improve the code. There will be more,
much more, to say about this later.
The last post on this topic sounded a
skeptical note on the prospects for a new FIPS 140 validated module for OpenSSL 1.1 and
beyond. That post noted a rather improbable set of prerequisites for a new validation attempt;
ones I thought only a governmental sponsor could meet (as was the case for the five previous
open source based validations).
Multiple commercial vendors have offered to fund (very generously in some cases) a new validation
effort under terms that would guarantee them a proprietary validation, while not guaranteeing
an open source based validation. At one point we actually came close to closing a deal that would
have funded an open source based validation attempt in exchange for a limited period of exclusivity;
a reasonable trade-off in my opinion. But, I eventually concluded that was too risky given an
uncertain reception by the FIPS validation bureaucracy, and we decided to wait for a “white knight”
sponsor that might never materialize.
We’ve just added a new severity level called “critical severity” to our
security policy. When we first introduced the policy, over a year ago, we just
had three levels, “Low”, “Moderate”, and “High”. So why did we add “Critical” and
why are we not using someone else’s standard definitions?
After introducing the new policy we started giving everyone a headsup when we
were due to release OpenSSL updates that included security fixes. The headsup
doesn’t contain any details of the issues being fixed apart from the maximum
severity level and a date a few days in the future.