National Vulnerability Database - Last 8 Days - Analyzed.
** DISPUTED ** GNOME Seahorse through 3.30 allows physically proximate attackers to read plaintext passwords by using the quickAllow dialog at an unattended workstation, if the keyring is unlocked. NOTE: this is disputed by a software maintainer because the behavior represents a design decision.
National Vulnerability Database - Last 8 Days - Not Analyzed.
Cross-site scripting (XSS) vulnerability on Google Search Appliance (GSA) devices before 7.0.14.G.216 and 7.2 before 7.2.0.G.114, when dynamic navigation is configured, allows remote attackers to inject arbitrary web script or HTML via input included in a SCRIPT element.
The OpenSSL Management Committee has been looking at the versioning scheme that
is currently in use. Over the years we’ve received plenty of feedback about the
“uniqueness” of this scheme, and it does cause some confusion for some users. We
would like to adopt a more typical version numbering approach.
The current versioning scheme has this format:
The new scheme will have this format:
In practical terms our “letter” patch releases become patch numbers and “fix”
is dropped from the concept. In future, API/ABI compatibility will only be
guaranteed for the same MAJOR version number. Previously we guaranteed
API/ABI compatibility across the same MAJOR.MINOR combination. This more closely
aligns with the expectations of users who are familiar with semantic versioning.
We are not at this stage directly adopting semantic versioning because it would
mean changing our current LTS policies and practices.
The current 1.1.1 and 1.0.2 versioning scheme will remain unchanged.
The current development version (master branch) will be identified as version
3.0.0. The OpenSSL FIPS module currently under development will also follow this
versioning scheme. We are skipping the 2.0.0 major version because the previous
OpenSSL FIPS module has already used this number.
OpenSSL version 3.0.0 will be the first version that we release under the Apache
License 2.0. We will not be applying the Apache License to earlier releases of
The OpenSSL Management Committee (OMC) on behalf of the OpenSSL Project would
like to formally express its thanks to the following organisations
for agreeing to sponsor the next
FIPS validation effort: Akamai Technologies, Blue Cedar, NetApp, Oracle, VMware.
Four weeks ago, the OpenSSL team gathered with many of the organisations
sponsoring the next FIPS module for a face-to-face meeting in Brisbane,
We got a great deal accomplished during that week. Having most of
the fips-sponsor organisations in the same location helps ensure that
we are all on the same page for the decisions we need to make going forward.
The fips-sponsor gathering (hosted by Oracle, Brisbane) involved a diverse
group of people:
It has been more than seven years since the commencement of the previous
FIPS140 module work and many things have changed during that time, both
in terms of requirements of the Cryptographic Module Validation Program
(CMVP) and the OpenSSL code base.
For the current validation effort, input and assistance from a small
group (the five fips-sponsors) is essential to achieving the outcomes of
the project in this area - a validated module that is usable
by itself and can also form the foundation for other companies to perform
their own validations for any areas where there are specific requirements
outside the general scope.
As the project moves from high-level design to detailed design,
prototyping, development, testing, documentation and quality assurance,
we plan to make information available to the OpenSSL community for review
and comment - as the next FIPS140 module will be substantially different
to the previous approaches.
We are mindful of the end-of-life date for OpenSSL-1.0.2 (31-Dec-2019)
and the end-of-life (sunset date) of the existing OpenSSL FIPS Object
Object (29-Jan-2022) and our objective remains to have a validated
cryptographic module in place well before 31-Dec-2019.
After two years of work we are excited to be releasing our latest version today -
OpenSSL 1.1.1. This is also our new Long Term Support (LTS) version and so we
are committing to support it for at least five years.
OpenSSL 1.1.1 has been a huge team effort with nearly 5000 commits having been
made from over 200 individual contributors since the release of OpenSSL 1.1.0.
These statistics just illustrate the amazing vitality and diversity of the
OpenSSL community. The contributions didn’t just come in the form of commits
though. There has been a great deal of interest in this new version so thanks
needs to be extended to the large number of users who have downloaded the beta
releases to test them out and report bugs.
The headline new feature is TLSv1.3. This new version of the Transport Layer
Security (formerly known as SSL) protocol was published by the IETF just one
month ago as RFC8446. This is a major rewrite of the standard and introduces
significant changes, features and improvements which have been reflected in the
new OpenSSL version.
What’s more is that OpenSSL 1.1.1 is API and ABI compliant with OpenSSL 1.1.0 so
most applications that work with 1.1.0 can gain many of the benefits of TLSv1.3
simply by dropping in the new OpenSSL version. Since TLSv1.3 works very
differently to TLSv1.2 though there are a few caveats that may impact a
minority of applications. See the
TLSv1.3 page on the OpenSSL wiki
for more details.
Some of the benefits of TLSv1.3 include:
Improved connection times due to a reduction in the number of round trips
required between the client and server
The ability, in certain circumstances, for clients to start sending encrypted
data to the server straight away without any round trips with the server
required (a feature known as 0-RTT or “early data”).
Improved security due to the removal of various obsolete and insecure
cryptographic algorithms and encryption of more of the connection handshake
Other features in the 1.1.1 release include:
Complete rewrite of the OpenSSL random number generator to introduce the
The default RAND method now utilizes an AES-CTR DRBG according to NIST
standard SP 800-90Ar1.
Support for multiple DRBG instances with seed chaining.
There is a public and private DRBG instance.
The DRBG instances are fork-safe.
Keep all global DRBG instances on the secure heap if it is enabled.
The public and private DRBG instance are per thread for lock free operation
Support for various new cryptographic algorithms including:
SHA512/224 and SHA512/256
EdDSA (including Ed25519 and Ed448)
X448 (adding to the existing X25519 support in 1.1.0)
A new STORE module, which implements a uniform and URI based reader of stores
that can contain keys, certificates, CRLs and numerous other objects.
Since 1.1.1 is our new LTS release we are strongly advising all users to upgrade
as soon as possible. For most applications this should be straight forward if
they are written to work with OpenSSL 1.1.0. Since OpenSSL 1.1.0 is not an LTS
release it will start receiving security fixes only with immediate affect as per
announcement and as
published in our
release strategy. It will
cease receiving all support in one years time.
Our previous LTS release (OpenSSL 1.0.2) will continue to receive full support
until the end of this year. After that it will receive security fixes only. It
will stop receiving all support at the end of 2019. Users of that release are
strongly advised to upgrade to OpenSSL 1.1.1.
The OpenSSL team will now be moving our focus to the next release which will see
us developing a new FIPS module.
What this means for the OpenSSL community is that there is now a larger group
of active developers who have the ability to review and commit code to our
source code repository. These new committers will help the existing
committers with our review process (i.e., their reviews count towards approval)
which we anticipate will help us keep on top of
the github issues
and pull request queues.
As always, we welcome comments on submissions and technical reviews of
pull requests from anyone in the community.
Note: All submissions must be reviewed and approved by at least two committers,
one of whom must also be an OMC member as described in
the project bylaws
As well as the above additions to our team, Rich Salz has now left his
roles as OpenSSL Management Committee member and OpenSSL committer. Rich
has had a long standing association with the project and we would like
to thank him for his many significant contributions over the years.