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.

As announced here recently Oracle remains a sponsor but will hopefully not be the only sponsor for long. We will continue to partner with Acumen and we have been working extensively with Ashit Vora and Tony Busciglio there to sort out some new ideas.

No code has been written yet as we’re still developing a technical strategy and design. We’ve considered some new approaches to structuring the module, perhaps even as a related set of “bound” modules instead of one monolithic module as for past validations. Carefully sorting through the implications of design decisions for FIPS 140 requirements is a tedious but necessary process, and I think we’ll make faster progress overall by not rushing to the coding stage.

As always we’re interested in hearing from stakeholders (and especially prospective sponsors!), please contact me at marquess@openssl.com or Jim Wright at Oracle at jim.wright@oracle.com.

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.

Read on for more details.

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 bad news is that the Oracle funding will only partially cover the FIPS module work (for perhaps a couple of months), at which point we may have to set that work aside. Hand-to-mouth funding is not a new experience for us though so we’ll worry about that later.

The FIPS module is heavily shaped and constrained (one could even say distorted and contorted) by FIPS 140 requirements. Those requirements (or technically speaking the interpretation of those requirements) has changed considerably since our last open source based validation in 2013, so we’re starting with a careful study of the many requirements changes that have accumulated since then. That study will generate a lot of questions for the accredited test lab, as the practical application of the formal requirements to working code is rarely obvious to anyone.

One goal for this new FIPS module is to make a clean break from the legacy code base of the previous module, which started as a stripped and bastardized version of an old copy of OpenSSL. We’ll be making the new module as simple as possible without extraneous vestigial code. It will live in a new separate git repository, though don’t expect to see a lot of code right away as we work through the requirements questions.

As before the FIPS module will be primarily intended for use with OpenSSL proper, though we hope to minimize (or even eliminate) FIPS specific code in OpenSSL by enhancing the current ENGINE interface. The new FIPS module will have an internal API (with non-opaque structures) that in turn will be wrapped in a higher level ENGINE interface package external to the “cryptographic module boundary”. All three components (formal validated module, module interface wrapper, and OpenSSL proper) will as before be usable as a seamless “FIPS capable” OpenSSL library.

The test suite software will interface with the module directly, and that code will be separate from the module itself. We’ll be sorting out the outlines of these separate components as soon as we’ve confirmed we understand the new requirements.

I’ll blog more as we finalize additional details.

(Vlad has published a Russian translation of this post at http://howtorecover.me/udalenie-nekotorogo-koda. Thanks, Vlad!)

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.

This is another in the series of posts about decisions we made at our face-to-face meeting a couple of weeks ago.

We updated the project roadmap.

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.

We have also set ourselves major goals of increasing our code coverage and protocol-level testing. In addition, all new API’s must be documented, and the entire set of SSL API’s will also be documented. The script util/find-undoc-api.pl lists them. If you’re inclined to help write some documentation, please feel free!

There are a variety of other crypto-nerd things we are looking at, so please see the roadmap for details.

The second point I want to mention in this post is that we have sketched out a platform policy. This is, admittedly, an overdue item from our first meeting two years ago. The first step will be to review all targets in the configuration scripts, and classify them according to the categories mentioned in the platform policy by our next release.

Which, in case I failed to mention it, will include TLS 1.3 :)