Mail Archives: djgpp-announce/2019/07/10/17:20:39
This is a port of OpenSSL 1.0.2s to MSDOS/DJGPP.
The OpenSSL Project is an Open Source toolkit implementing the Secure
Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols
as well as a full-strength general purpose cryptography library. OpenSSL
is based on the excellent SSLeay library developed from Eric A. Young and
Tim J. Hudson. The OpenSSL toolkit is licensed under a dual-license (the
OpenSSL license plus the SSLeay license) situation, which basically means
that you are free to get and use it for commercial and non-commercial
purposes as long as you fulfill the conditions of both licenses.
DJGPP specific changes.
=======================
Fortunately, OpenSSL has been supporting DJGPP out-of-the-box so there
is no need for major adjustments of the source code itself. Neitherless
there are made assumptions about the file system used and its capabilities
that require some changes in the perl configuration scripts and in the way
source package is unzipped. This port has been created because 1.0.2 is
the Long Term Support (LTS) version (support will be provided until 31st
December 2019) and the 1.0.1 version is currently only receiving security
bug fixes and all support will be discontinued for this version on 31st
December 2016.
- the configure script assumes that DJGPP provides termio so it defines
TERMIO instead of TERMIOS as used to be. This had to be reverted.
- undefining the DEVRANDOM_EGD macro because neither MS-DOS nor FreeDOS
provide 'egd' sockets.
- all the adjustments required for the use of the DJGPP port of the
current version of the Watt-32 library.
- the new macro HAS_LFN_SUPPORT checks if underlying file system supports
long file names or not.
- the new function dosify_filename replaces leading dot in passed file
name if file system does not support LFN. It also replaces all leading
dots in the dirname part and the basename part of the file name.
- all these changes have found their way into the new OpenSSl 1.1.0 version
but will not become part neither of version 1.0.1 nor version 1.0.2.
That is because both versions are maintaining versions only and will
not offer new OS/port specific features anymore.
- all new DJGPP specific files are store in the /djgpp directory.
- to install, configure and compile the sources LFN support is required.
- as usual the /djgpp directory contains also the diffs file. It shows how
I have changed some of the perl scripts used during the configuration and
building steps to check for the OS used and to copy the files instead of
trying to create links even if this is possible.
- the binaries, headers and libraries will be installed in the corresponding
directories of the DJGPP installation tree. All documentation will be
installend in /dev/env/DJDIR/share/ssl/man. This means that you will have
to adjust your MANPATH in djgpp.env if you want that the man program finds
these new manpages.
- to be able to configure and compile this port, the DJGPP port of perl
must be installed. openssl uses a mix of perl scripts and Makefiles to
configure and compile the sources. I have used perl588b but the previous
one may work as well but I have never tested this.
- to be able to configure and compile this port, the DJGPP port of WATT-32
must be installed. It can be downloaded as:
ftp://ftp.delorie.com/pub/djgpp/current/v2tk/wat3211b.zip
After having installed the port make sure that the WATT_ROOT environment
variable points to the directory where the headers and the library reside.
This is:
set WATT_ROOT=/dev/env/DJDIR/net/watt
Due to the dependency of WATT-32 and the required value of the WATT_ROOT
environment variable, the source package is not configured at all. You
have to install WATT-32 first and then you can configure and build openssl
as described in the original INSTALL.DJGPP file.
- the port has been configured and compiled to support for zlib compression.
The zlib port used is
ftp://ftp.delorie.com/pub/djgpp/current/v2tk/zlb1211b.zip
but any other version of the port may work as well.
- the test suite passes except for the last test that requires some
certificate that needs to be requested. For some test, it is also
required that the port of GNU bc is installed.
- the binary package of openssl ist not completely SFN clean. But this
concerns the manpages only. Neither the libraries nor the headers are
affected. I do not have the time to invent SFN clean names for hundreds
of manpages which names may change and become useless with the next
openssl update. Of course, the headers and libraries are 8.3 clean
and the use of the libraries do not require LFN support at all.
- as any cryptographic software, openssl needs a source of unpredictable
data to work correctly. Many open source operating systems provide a
"randomness device" (/dev/urandom or /dev/random) that serves this
purpose. As of version 0.9.7f of openssl the DJGPP port checks upon
/dev/urandom$ for a 3rd party "randomness" DOS driver. One such driver,
NOISE.SYS, can be obtained from "http://www.rahul.net/dkaufman/index.html"
as:
http://www.rahul.net/dkaufman/noise063a2.zip
Please read the instructions carefully. This driver works on DOS and
may be on some versions of Windows but it does not work for all versions
of Windows. For XP it does not work and I have found no replacement.
This means that for WinXP and probably for Win2K there is there is
no "randomness" support for openssl available.
- most but not all programs of the /examples directory can be successfully
compiled but they may not work. I have no intention to fix them, neither
less they may serve as example how to use the library and how to compile
and link your application with this library together with the WATT-32
library and the zlib library.
- the port has been configured and compiled on WinXP SP3 and on Win98SE.
There is no guarantee that this may be possible with any other DOS-
like OS. Due to the use of long file names it will not be possible
to configure and compile without LFN support.
- the port has been compiled using gcc346b, bnu232b and djdev205 (CVS
repository build).
- configuring, compiling and running the test suite takes around 02:15 h
on WinXP installed on a virtual machine.
- configuring, compiling, running the test suite and installing takes
around 20 min on Win98SE installed on a virtual machine.
For further information about OpenSSL please read the man pages,
various README files and NEWS file. Also visit the home page of openssl.
Please note that I am not an user of openssl. I have only ported it because
I needed it to create another port. This means that I am not able to answer
openssl specific questions.
This is a verbatim extract of the CHANGES file:
-------------------------------------------------------------------------------
Changes between 1.0.2r and 1.0.2s [28 May 2019]
*) Change the default RSA, DSA and DH size to 2048 bit instead of 1024.
This changes the size when using the genpkey app when no size is given. It
fixes an omission in earlier changes that changed all RSA, DSA and DH
generation apps to use 2048 bits by default.
[Kurt Roeckx]
*) Add FIPS support for Android Arm 64-bit
Support for Android Arm 64-bit was added to the OpenSSL FIPS Object
Module in Version 2.0.10. For some reason, the corresponding target
'android64-aarch64' was missing OpenSSL 1.0.2, whence it could not be
built with FIPS support on Android Arm 64-bit. This omission has been
fixed.
[Matthias St. Pierre]
Changes between 1.0.2q and 1.0.2r [26 Feb 2019]
*) 0-byte record padding oracle
If an application encounters a fatal protocol error and then calls
SSL_shutdown() twice (once to send a close_notify, and once to receive one)
then OpenSSL can respond differently to the calling application if a 0 byte
record is received with invalid padding compared to if a 0 byte record is
received with an invalid MAC. If the application then behaves differently
based on that in a way that is detectable to the remote peer, then this
amounts to a padding oracle that could be used to decrypt data.
In order for this to be exploitable "non-stitched" ciphersuites must be in
use. Stitched ciphersuites are optimised implementations of certain
commonly used ciphersuites. Also the application must call SSL_shutdown()
twice even if a protocol error has occurred (applications should not do
this but some do anyway).
This issue was discovered by Juraj Somorovsky, Robert Merget and Nimrod
Aviram, with additional investigation by Steven Collison and Andrew
Hourselt. It was reported to OpenSSL on 10th December 2018.
(CVE-2019-1559)
[Matt Caswell]
*) Move strictness check from EVP_PKEY_asn1_new() to EVP_PKEY_asn1_add0().
[Richard Levitte]
Changes between 1.0.2p and 1.0.2q [20 Nov 2018]
*) Microarchitecture timing vulnerability in ECC scalar multiplication
OpenSSL ECC scalar multiplication, used in e.g. ECDSA and ECDH, has been
shown to be vulnerable to a microarchitecture timing side channel attack.
An attacker with sufficient access to mount local timing attacks during
ECDSA signature generation could recover the private key.
This issue was reported to OpenSSL on 26th October 2018 by Alejandro
Cabrera Aldaya, Billy Brumley, Sohaib ul Hassan, Cesar Pereida Garcia and
Nicola Tuveri.
(CVE-2018-5407)
[Billy Brumley]
*) Timing vulnerability in DSA signature generation
The OpenSSL DSA signature algorithm has been shown to be vulnerable to a
timing side channel attack. An attacker could use variations in the signing
algorithm to recover the private key.
This issue was reported to OpenSSL on 16th October 2018 by Samuel Weiser.
(CVE-2018-0734)
[Paul Dale]
*) Resolve a compatibility issue in EC_GROUP handling with the FIPS Object
Module, accidentally introduced while backporting security fixes from the
development branch and hindering the use of ECC in FIPS mode.
[Nicola Tuveri]
Changes between 1.0.2o and 1.0.2p [14 Aug 2018]
*) Client DoS due to large DH parameter
During key agreement in a TLS handshake using a DH(E) based ciphersuite a
malicious server can send a very large prime value to the client. This will
cause the client to spend an unreasonably long period of time generating a
key for this prime resulting in a hang until the client has finished. This
could be exploited in a Denial Of Service attack.
This issue was reported to OpenSSL on 5th June 2018 by Guido Vranken
(CVE-2018-0732)
[Guido Vranken]
*) Cache timing vulnerability in RSA Key Generation
The OpenSSL RSA Key generation algorithm has been shown to be vulnerable to
a cache timing side channel attack. An attacker with sufficient access to
mount cache timing attacks during the RSA key generation process could
recover the private key.
This issue was reported to OpenSSL on 4th April 2018 by Alejandro Cabrera
Aldaya, Billy Brumley, Cesar Pereida Garcia and Luis Manuel Alvarez Tapia.
(CVE-2018-0737)
[Billy Brumley]
*) Make EVP_PKEY_asn1_new() a bit stricter about its input. A NULL pem_str
parameter is no longer accepted, as it leads to a corrupt table. NULL
pem_str is reserved for alias entries only.
[Richard Levitte]
*) Revert blinding in ECDSA sign and instead make problematic addition
length-invariant. Switch even to fixed-length Montgomery multiplication.
[Andy Polyakov]
*) Change generating and checking of primes so that the error rate of not
being prime depends on the intended use based on the size of the input.
For larger primes this will result in more rounds of Miller-Rabin.
The maximal error rate for primes with more than 1080 bits is lowered
to 2^-128.
[Kurt Roeckx, Annie Yousar]
*) Increase the number of Miller-Rabin rounds for DSA key generating to 64.
[Kurt Roeckx]
*) Add blinding to ECDSA and DSA signatures to protect against side channel
attacks discovered by Keegan Ryan (NCC Group).
[Matt Caswell]
*) When unlocking a pass phrase protected PEM file or PKCS#8 container, we
now allow empty (zero character) pass phrases.
[Richard Levitte]
*) Certificate time validation (X509_cmp_time) enforces stricter
compliance with RFC 5280. Fractional seconds and timezone offsets
are no longer allowed.
[Emilia Käsper]
-------------------------------------------------------------------------------
The port has been compiled using djdev205 (repository code) and consists
of two packages that can be downloaded from ftp.delorie.com and mirrors
as (time stamp 2019-07-09):
OpenSSL 1.0.2s binary, headers, libraries and man format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl102sb.zip
OpenSSL 1.0.2s source:
ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl102ss.zip
Send OpenSSL specific bug reports to <openssl-bugs AT openssl DOT org>.
Send suggestions and bug reports concerning the DJGPP port to
comp.os.msdos.djgpp or <djgpp AT delorie DOT com>.
If you are not sure if the failure is really a openssl failure
or a djgpp specific failure, report it here and *not* to
<openssl-bugs AT openssl DOT org>.
Enjoy.
Guerrero, Juan Manuel <juan DOT guerrero AT gmx DOT de>
- Raw text -