OpenSSL Security Advisory [12 June 2018]
Client DoS due to large DH parameter (CVE-2018-0732)
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.
Due to the low severity of this issue we are not issuing a new release of
OpenSSL 1.1.0 or 1.0.2 at this time. The fix will be included in OpenSSL 1.1.0i
and OpenSSL 1.0.2p when they become available. The fix is also available in
commit ea7abeeab (for 1.1.0) and commit 3984ef0b7 (for 1.0.2) in the OpenSSL git
This issue was reported to OpenSSL on 5th June 2018 by Guido Vranken who also
developed the fix.
Date: Tue, 12 Jun 2018 11:32:21 +0100
From: Matt Caswell <[hidden email]>
To: [hidden email]
Subject: Re: [openssl-users] OpenSSL 1.1.0: How to get X509_STORE from
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8
On 12/06/18 10:58, Stephan M?hlstrasser wrote:
> In OpenSSL 1.0.2 this was no problem as the "X509_STORE *store_ctx"
> member of the X509_LOOKUP structure was directly accessible. But in
> OpenSSL 1.1.0 the X509_LOOKUP structure is opaque, and as far as I can
> see there is no API function available that would retrieve the
> X509_STORE pointer from a X509_LOOKUP pointer.
> Is this intentional, or was this an omission when making the X509_LOOKUP
> structure opaque in OpenSSL 1.1.0?
It was an omission that is fixed in the latest dev version of OpenSSL
1.1.0. See this commit:
On 07/06/18 06:14, Sampei wrote:
> t?s a server installed many many years ago and there are applications
> which are no used.
> Server is too late and I have new server (latest Centos 6) for
> migrating where I installed latest version.
> I?d like to take to new server all certificate database (certificated
> included) which I created.
> Openssl is only tool to create test certificates.
> I don?t know if there are apps which are using the e configs, but I
> think no.
this has little to do with OpenSSL itself and more with PKI management.
Basically, your problem seems to be that you have an older server and
you don't know where the certificates and private keys (i.e. the PKI)
were stored. What you need to do, is find out where the certifcates are
held, together with the index.txt file. In order to do so, you could use
? find / -name '*.pem'
? find / -name index.txt
and check all directories where such files are found. This will be a
lengthy process, as the find command has to traverse the entire filesystem.
Sent: Wednesday, June 13, 2018 1:21 PM
To: '[hidden email]'
Cc: Brian.Ng; Mojo.Huang
Subject: Advantech openssl compatibility issue
Dear support team
We met openssl crash issue on our Intel Atom C3000 SoC platform.
Openssl crashes when run "s_client -connect IP:Port" command.
In win10 event viewer it show "Faulting module name:LIBEAY32.dll, version:18.104.22.168......". (Figure 1)
The issue only happened to "1.0.2h" or older version. (Table 1)
And other CPU/Chipset on our side can work normally with same command.
Can you help to explain what changes are made between "1.0.2h" and "1.0.2i" that may cause this issue?
Please let me know if you need more info, thank you.