On 13/09/2018 03:24, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Jakob Bohm
Sent: Wednesday, September 12, 2018 17:18
Testing your OpenSSL download with the HTTPS security bites its
own tail, especially if your download tool uses an (older) version
of OpenSSL to check the connection.
And as I noted in my previous email, the HTTPS PKI is rubbish. Historically
there have been numerous successful attacks on it, even in modes that do not
involve user intervention.
It's better than nothing, but checking the PGP signature is defense in depth
that does not rely solely on the integrity of the HTTPS PKI.
But unless you have an established personal list of GPG/PGP keys
you have checked against their holders in person yourself, checking
the HTTPS certificate of the OpenSSL.org web server is pretty much
all you can do to distinguish between a genuine and a fake first time
OpenSSL download (signatures on later downloads can be compared to
previous downloadsfor some degree of signature consistency).
There are plenty of other channels that can be used to validate the PGP public
key used to confirm the signature of the OpenSSL tarball. None of them are
secure in themselves, but by using multiple channels, the defender greatly
increases the attacker's work factor and risk of discovery. That's the whole
point of defense in depth.
It's not hard to learn how to install an OpenPGP implementation (most likely
gpg) and use it to verify a detached signature. There are many tutorials
available online. I don't think a lack of experience with PGP or gpg is a valid
excuse for not validating the signature.
Of cause some real knowledge is needed to not use the OpenSSL source
code incorrectly, unless you are merely compiling other peoples
software exactly as instructed.
Yes. And this is a much more likely source of problems than a counterfeit
OpenSSL distribution.
To make it clear, I am very experienced and do in fact check the gpg
signature
if possible. I was trying to give good advice to the OP based on my
experience
checking the only ways that the OpenSSL foundation provides.
The OpenPGP/GPG key servers that you suggested, by design, accept any
made up
key identity and thus provide no indication of validity, so just
downloading
the key from there is a non-solution to the problem of bootstrapping
trust in
someones first OpenSSL download.
To my knowledge the only ways to check that the .asc file was signed
with an
authorized release key are:
A) Trusting that the HTTPS connection to the download server is
uncompromised,
essentially treating at least the first such signature as a glorified
.sha256 file.
B) Checking doc/fingerprints.txt in the previous tarball and hoping the
OpenSSL
foundation double checks the correctness of that file before signing
a new
tarball.
C) Using the text (BUT NOT THE INSECURE LINKS) on
https://www.openssl.org/community/omc.html
But this lists some unauthorized keys, and also relies on that same
HTTPS
certificate.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
