Mail Archives: djgpp-announce/2017/05/25/14:51:22
This is a port of OpenSSL 1.0.2k 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
assumptions made 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/wat3222br6.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. There is no
guarantee that this may be possible with any other DOS-like OS. Due
to the massive use of long file names it will not be possible to configure
and compile without LFN support.
- the port has been compiled using gcc346b, bnu228b and djdev206.
- configuring, compiling and running the test suite takes around 02:15 h.
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.2j and 1.0.2k [26 Jan 2017]
*) Truncated packet could crash via OOB read
If one side of an SSL/TLS path is running on a 32-bit host and a specific
cipher is being used, then a truncated packet can cause that host to
perform an out-of-bounds read, usually resulting in a crash.
This issue was reported to OpenSSL by Robert Święcki of Google.
(CVE-2017-3731)
[Andy Polyakov]
*) BN_mod_exp may produce incorrect results on x86_64
There is a carry propagating bug in the x86_64 Montgomery squaring
procedure. No EC algorithms are affected. Analysis suggests that attacks
against RSA and DSA as a result of this defect would be very difficult to
perform and are not believed likely. Attacks against DH are considered just
feasible (although very difficult) because most of the work necessary to
deduce information about a private key may be performed offline. The amount
of resources required for such an attack would be very significant and
likely only accessible to a limited number of attackers. An attacker would
additionally need online access to an unpatched system using the target
private key in a scenario with persistent DH parameters and a private
key that is shared between multiple clients. For example this can occur by
default in OpenSSL DHE based SSL/TLS ciphersuites. Note: This issue is very
similar to CVE-2015-3193 but must be treated as a separate problem.
This issue was reported to OpenSSL by the OSS-Fuzz project.
(CVE-2017-3732)
[Andy Polyakov]
*) Montgomery multiplication may produce incorrect results
There is a carry propagating bug in the Broadwell-specific Montgomery
multiplication procedure that handles input lengths divisible by, but
longer than 256 bits. Analysis suggests that attacks against RSA, DSA
and DH private keys are impossible. This is because the subroutine in
question is not used in operations with the private key itself and an input
of the attacker's direct choice. Otherwise the bug can manifest itself as
transient authentication and key negotiation failures or reproducible
erroneous outcome of public-key operations with specially crafted input.
Among EC algorithms only Brainpool P-512 curves are affected and one
presumably can attack ECDH key negotiation. Impact was not analyzed in
detail, because pre-requisites for attack are considered unlikely. Namely
multiple clients have to choose the curve in question and the server has to
share the private key among them, neither of which is default behaviour.
Even then only clients that chose the curve will be affected.
This issue was publicly reported as transient failures and was not
initially recognized as a security issue. Thanks to Richard Morgan for
providing reproducible case.
(CVE-2016-7055)
[Andy Polyakov]
*) OpenSSL now fails if it receives an unrecognised record type in TLS1.0
or TLS1.1. Previously this only happened in SSLv3 and TLS1.2. This is to
prevent issues where no progress is being made and the peer continually
sends unrecognised record types, using up resources processing them.
[Matt Caswell]
-------------------------------------------------------------------------------
The port has been compiled using djdev205 and consists of two packages that
can be downloaded from ftp.delorie.com and mirrors as (time stamp 2017-05-20):
OpenSSL 1.0.2k binary, headers, libraries and man format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl102kb.zip
OpenSSL 1.0.2k source:
ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl102ks.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 -