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.
At the face to face
last year we discussed future funding models, and we are exploring a range of
possible options. One suggestion raised was we could sell more support
contracts and give those support contract users patches for security issues in
advance.
But before we can even discuss this as an option we would have to change
our public stance. Our security policy since 2014 has stated we would
not do this and currently reads:
The OpenSSL OMC met last month for a two-day face-to-face meeting in London,
and like previous F2F meetings, most of the team was present and we addressed
a great many issues. This blog posts talks about some of them,
and most of the others will get their own blog posts, or notices, later.
Red Hat graciously hosted us for the two days, and both Red Hat and Cryptsoft
covered the costs of their employees who attended.
One of the overall threads of the meeting was about increasing the
transparency of the project. By default, everything should be done in
public. We decided to try some major changes to email and such.
Today I have had great pleasure in attending the Real World Crypto 2018
conference in Zürich in order to receive the
Levchin prize on behalf of the OpenSSL team.
The Levchin prize for Real World Cryptography recognises up to two groups or
individuals each year who have made significant advances in the practice of
cryptography and its use in real-world systems. This year one of the two
recipients is the OpenSSL team. The other recipient is
Hugo Krawczyk.
For as long as I have been involved in the OpenSSL project there has been one
constant presence: Steve Henson. In fact he has been a part of the project since
it was founded and he is the number 1 committer of all time (by a wide margin).
I recall the first few times I had any dealings with him being somewhat in awe
of his encyclopaedic knowledge of OpenSSL and all things crypto. Over the years
Steve has made very many significant contributions both in terms of code but
also in terms of being an active member of the management team.
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).
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.