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.
The next release will include a completely overhauled version of the random
number facility, the RAND API. The default RAND method is now based
on a Deterministic Random Bit Generator (DRBG) implemented according to
the NIST recommendation 800-90A.
We have also edited the documentation, allowed
finer-grained configuration of how to seed the generator, and updated
the default seeding mechanisms.
There will probably be more changes before the release is made, but they
should be comparatively minor.
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.
This is another update on our effort to re-license the OpenSSL software.
Our previous post in March was about the
launch of our effort to reach all contributors, with the hope that they
would support this change.
So far, about 40% of the people have responded. For a project that is
as old as OpenSSL (including its predecessor, SSLeay, it’s around 20 years)
that’s not bad.
We’ll be continuing our efforts over the next couple of months to
contact everyone.
Of those people responding, the vast majority have been in favor of
the license change – less then a dozen objected. This post describes
what we’re doing about those and how we came to our conclusions. The
goal is to be very transparent and open with our processes.
We announced back in October
that we would be changing from a single OpenSSL Project Team to having
an OpenSSL management committee
and a set of committers which
we planned to expand to enable the greater involvement from the community.
Now that we have in place committer guidelines,
we have invited the first set of external (non-OMC) community members to become committers and
they have each accepted the invitation.
Note: This is an outdated version of this blog post. This information is now
maintained in a wiki page. See
here for the latest version.
The forthcoming OpenSSL 1.1.1 release will include support for TLSv1.3. The new
release will be binary and API compatible with OpenSSL 1.1.0. In theory, if your
application supports OpenSSL 1.1.0, then all you need to do to upgrade is to drop
in the new version of OpenSSL when it becomes available and you will
automatically start being able to use TLSv1.3. However there are some issues
that application developers and deployers need to be aware of. In this blog post
I am going to cover some of those things.
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:
This post talks about OpenSSL and threads. In particular, using OpenSSL
in multi-threaded applications. It traces through the history, explains
what was changed for the 1.1.0 release, and will hopefully provide some
guidance to developers.
While none of the behaviors have really changed, and therefore none of
this should be new information, the documentation has not been as
clear as it could, or should, be. Therefore, some readers might be
surprised by what’s in this post.
In short, OpenSSL has always, and only, supported the concept of
locking an object and sometimes it locks its internal
objects. Read on for more details.
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.