DROWN - Cross-protocol attack on TLS using SSLv2 (CVE-2016-0800)

Public Date: March 1, 2016, 12:00 am
Updated -
Resolved Status
Important Impact

Red Hat Product Security has been made aware of a vulnerability in the SSLv2 protocol, which has been assigned CVE-2016-0800 and is used in a cross-protocol attack referred to as DROWN - Decrypting RSA using Obsolete and Weakened eNcryption. This issue was publicly disclosed on March 1, 2016 and has been rated as Important .

Background Information

A group of security researchers discovered that SSLv2 (Secure Sockets Layer protocol version 2.0) is vulnerable to the Bleichenbacher RSA padding oracle attack, which can be used to decrypt RSA cipher text without the knowledge of the matching private RSA key. This can be done by observing responses from a server that has the private key and performs the decryption of attacker-provided cipher texts using that key. The researchers also demonstrated a new cross-protocol attack which allows decryption of SSL/TLS sessions using newer protocol versions - SSLv3 or any current TLS (Transport Layer Security) version (1.0 - 1.2) - using this SSLv2 weakness. This flaw is a SSLv2 protocol issue and affects all implementations of the protocol. Researchers refer to this attack as general DROWN.

Additionally, flaws were found in the SSLv2 protocol implementation in the OpenSSL cryptography and SSL/TLS library, which make it possible to perform a more efficient variant of the DROWN attack, referred to as special DROWN. These issues were assigned CVE-2016-0703 and CVE-2016-0704 , and were already recently corrected as part of the fix for CVE-2015-0293 .

Further details of this attack can be found in the researchers' paper titled DROWN: Breaking TLS using SSLv2 at https://drownattack.com/ .

Acknowledgments

Red Hat would like to thank the OpenSSL project for reporting these issues. Upstream acknowledges Nimrod Aviram and Sebastian Schinzel as the original reporters.


Impacted Products

This issue has been rated as having Important impact by Red Hat Product Security.

The following Red Hat Product versions are impacted:

  • Red Hat Enterprise Linux 4*
  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Red Hat JBoss Enterprise Web Server 2.1.0 (See FAQ below)
  • Red Hat JBoss Enterprise Web Server 3.0 (See FAQ below)
  • Red Hat JBoss Enterprise Application Platform 5.2 (See FAQ below)
  • Red Hat JBoss Enterprise Application Platform 6.4 (See FAQ below)

All versions of NSS shipped with Red Hat Enterprise Linux 5, 6, and 7 are not affected by this vulnerability.

*An active ELS subscription is required for access to this patch in RHEL 4. Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active ELS subscription.

What is the Red Hat Enterprise Linux Extended Life Cycle Support Add-On (ELS)?

Attack description and impact

The DROWN attack described by the researchers consists of the following steps:

  • An attacker first needs to record a certain number of SSL/TLS sessions between client and server using any version of the protocol and using RSA cipher suites. One of these recorded sessions will be decrypted. Researchers indicate that approximately 1,000 sessions are sufficient for the attack.

  • Subsequently, the attacker opens many SSLv2 connections to the server. For some of these connections, the attacker needs to brute force a 40-bit (if one of the SSLv2 EXPORT ciphers can be used) or a 56-bit (for cipher suite using DES) session key. Researchers estimate that approximately 40,000 connections are needed.

  • After that, the attacker is able to decrypt "premaster secret" data from one of the originally recorded handshakes. That data is used to generate symmetric session keys, and hence decrypt the whole recorded SSL/TLS session. Additional sensitive data can be obtained form the decrypted session, such as authentication credentials or cookies.

Researchers indicate they were able to decrypt a TLS 1.2 handshake with a server using 2048 bit RSA keys using 1,000 recorded handshakes, 40,000 SSLv2 connections, and 250 offline computations. Their attack took less than 8 hours using resources of a public cloud provider at a cost of 440 USD.

They also indicate that the use of the special DROWN attack reduces the number of SSLv2 connections down to 14,000 and can be performed using a single workstation in less than 3 minutes. That makes it possible to use this flaw to perform an active man-in-the-middle (MITM) attack and impersonate a TLS server to connecting TLS client.

SSL and TLS libraries with SSLv2 support

Red Hat products include the following components that implement support for SSLv2 protocol. That support may be enabled based on how applications use these SSL/TLS libraries.

SSLv2 in OpenSSL

Applications using OpenSSL have to select a connection method to inform the library which SSL/TLS protocol versions they want to use. OpenSSL connection methods either enable a single protocol version, or the special method SSLv23 can be used to enable all protocol versions supported by the library. This is the most commonly used connection method. The SSLv2 protocol is automatically enabled when this method is selected. Applications have to explicitly set the SSL_OP_NO_SSLv2 option in the relevant SSL_CTX or SSL objects to disable SSLv2. While many applications do that, either unconditionally or based on their configuration, other applications use the default set of enabled protocols. Applications using the OpenSSL library are therefore likely to run with SSLv2 enabled.

The following changes were applied to OpenSSL included in Red Hat products to address this issue:

  • The SSLv2 protocol is no longer enabled by default when using the SSLv23 connection method.
  • All SSLv2 cipher suites using 40 bit (EXPORT) or 56 bit (single DES) symmetric encryption keys are now disabled and can no longer be used. The following cipher suites are no longer available:
    • EXP-RC2-CBC-MD5 / SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
    • EXP-RC4-MD5 / SSL_CK_RC4_128_EXPORT40_WITH_MD5
    • DES-CBC-MD5 / SSL_CK_DES_64_CBC_WITH_MD5
  • The OpenSSL versions in the openssl packages in all updates for Red Hat Enterprise Linux 4 and 5 now check the OPENSSL_ENABLE_SSL2 environment variable and if it is defined, SSLv2 is enabled by default when using the SSLv23 connection method. This environment variable can be used to re-enable SSLv2 if needed.

The SSLv2 connection method is not affected by the change to the SSLv23 connection method and can still be used to establish connections using SSLv2 protocol.

Also note that while the DEFAULT cipher list in OpenSSL versions as shipped in Red Hat Enterprise Linux 6 and 7 excludes all SSLv2 cipher suites, this default does not prevent servers from accepting SSLv2 connections from clients that force the use of a disabled cipher suite. This issue was assigned CVE-2015-3197 and is also fixed in updates that address the DROWN issue.

SSLv2 in NSS (Network Security Services)

The NSS cryptography library implements the SSLv2 protocol, but it does not enable it by default. Applications need to explicitly ask the library to enable SSLv2 to use it. The NSS versions shipped with Red Hat Enterprise Linux 7 do not allow enabling SSLv2 protocol at all. Applications using the NSS library are unlikely to run with SSLv2 enabled.

As the NSS library does not enable SSLv2 by default, no immediate updates are planned to address the DROWN issue. Future updates in Red Hat Enterprise Linux 6 are expected to disable the protocol in a similar way to how it is disabled in Red Hat Enterprise Linux 7.

SSL and TLS libraries without SSLv2 support

Red Hat products include the following components that implement some TLS or SSL protocol version, but do not implement support for SSLv2. Therefore, these components are not affected by this issue. Note that applications using these unaffected libraries may still be affected by the DROWN attack if they share their private RSA key with another application that uses an SSL/TLS library that supports SSLv2.

  • GnuTLS
  • OpenJDK (packages java-1.6.0-openjdk , java-1.7.0-openjdk , java-1.8.0-openjdk )
  • Oracle JDK (packages java-1.6.0-sun , java-1.7.0-oracle , java-1.8.0-oracle )
  • IBM JDK (packages java-1.6.0-ibm , java-1.7.0-ibm , java-1.7.1-ibm , java-1.8.0-ibm )

Frequently Asked Questions

Is SSLv2 enabled in the versions of Apache httpd web server shipped with Red Hat products?

The Apache httpd web server can use one of the following modules to provide HTTPS service:

  • mod_ssl - This module uses OpenSSL cryptographic library and is included as part of the Apache httpd web server distribution.
  • mod_nss - This module uses NSS cryptographic library and is developed and distributed separate from the Apache httpd project.

Both of these modules are included in Red Hat products.

The default settings for httpd using mod_ssl are:

  • The httpd versions shipped with Red Hat Enterprise Linux 7, in the httpd24 collection in Red Hat Software Collections, and with Red Hat JBoss Web Server 3 are based on upstream httpd version 2.4 and they can not be configured to enable SSLv2 protocol.

  • The httpd versions shipped with Red Hat Enterprise Linux 5 and 6, Red Hat JBoss Web Server 1 and 2, and Red Hat JBoss Enterprise Application Platform 6 are based on upstream httpd versions 2.2. Those versions can be configured to use SSLv2, however that protocol is disabled in the default configuration. The /etc/httpd/conf.d/ssl.conf configuration file includes the following configuration directive that disables SSLv2:

SSLProtocol all -SSLv2

																																													
  • The httpd versions shipped with Red Hat Enterprise Linux 4 are based on upstream httpd versions 2.0. The default configuration enables SSLv2, which can be disabled by adding the SSLProtocol directive as listed above to the /etc/httpd/conf.d/ssl.conf configuration file and restarting the httpd service.

The default settings for httpd using mod_nss are:

  • The mod_nss versions shipped with Red Hat Enterprise Linux 5, 6, and 7 do not enable SSLv2 by default. The /etc/httpd/conf.d/nss.conf configuration file includes, depending on the mod_nss package version, one of the following configuration directives that only enable SSLv3 or later, or TLSv1.0 or later:
NSSProtocol SSLv3,TLSv1
NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2

																																																					

How to disable SSLv2 in application X?

Refer to the knowledge base article Securing Application 'X' in RHEL 'Y' ? for information on how to change SSL/TLS related settings, such as enabled protocol versions, in various applications shipped with various Red Hat Enterprise Linux versions.

Do I need to update my EAP 6.4 installation?
EAP can be configured to use the Java cryptography provider (JSSE) or the native provider (APR/OpenSSL). If you are using the Apr/OpenSSL provider then you should take the following steps:
  • Red Hat Enterprise Linux

    • Upgrade OpenSSL for your version. (see the Resolve Tab of this article for RHSAs)

    • Windows or Solaris

      • An update for the openssl libraries will be available on the Customer Service Platform. This update will replace the libssl and libeay libraries and openssl application.

EAP 6.4 has been tested on Windows using APR/OpenSSL and although technically the OpenSSL library requires an update, EAP 6.4 will by default uses TLSv1 and rejects cipher requests for SSLv2 and SSLv3. EAP is not currently expected to be vulnerable to this flaw.

Do I need to update my EAP 5.2 installation?

EAP can be configured to use the Java cryptography provider (JSSE) or the native provider (APR/OpenSSL). If you are using the Apr/OpenSSL provider then you should take the following steps:

  • Red Hat Enterprise Linux

    • Upgrade OpenSSL for your version. (see the Resolve Tab of this article for RHSAs)

  • Windows or Solaris

    • An update for the openssl libraries will be available on the Customer Service Platform. This update will replace the libssl and libeay libraries and openssl application.

EAP 5.2 is being tested on Windows to assess vulnerability to this to this flaw.

Do I need to update my EWS 2.1 installation?

This flaw only affects WIndows and Solaris installations where APR/OpenSSL has been configured as the security provider. EWS 2.1 currently support SSLv2 and SSLv3.

If you are using the Apr/OpenSSL provider then you should take the following steps:

  • Red Hat Enterprise Linux

    • Upgrade OpenSSL for your version. (see the Resolve Tab of this article for RHSAs)

  • Windows or Solaris

    • An update for the openssl libraries will be available on the Customer Service Platform. This update will replace the libssl and libeay libraries and openssl application.

A: Yes EWS 2.1 is affected, updates will be available from the Customer Service Portal. This flaw only affects WIndows and Solaris installations where APR/OpenSSL has been configured as the security provider. The default JSSE configuration is not affected. Updates will be available from the Customer Service Portal.

Do I need to update my EWS 3.0.2 installation?

This flaw only affects WIndows and Solaris installations where APR/OpenSSL has been configured as the security provider. EWS 3.0.2 currently support SSLv2 and SSLv3. EWS 3.0.3 when released will no longer offer SSLv2 or SSLv3.

If you are using the Apr/OpenSSL provider then you should take the following steps:

  • Red Hat Enterprise Linux

    • Upgrade OpenSSL for your version. (see the Resolve Tab of this article for RHSAs)

  • Windows or Solaris

    • An update for the openssl libraries will be available on the Customer Service Platform. This update will replace the libssl and libeay libraries and openssl application.

What is the status of the tomcat-native package?

The tomcat native package is not affected by this flaw. the tomcat-native package relies on the system supplied OpenSSL libraries.

Related Issues

Divide-and-conquer session key recovery in SSLv2 ( CVE-2016-0703 ) Severity: Moderate

It was discovered that the SSLv2 servers using OpenSSL accepted SSLv2 connection handshakes that indicated non-zero clear key length for non-export cipher suites. An attacker could use this flaw to decrypt recorded SSLv2 sessions with the server by using it as a decryption oracle.

Bleichenbacher oracle in SSLv2 ( CVE-2016-0704 ) Severity: Moderate

It was discovered that the SSLv2 protocol implementation in OpenSSL did not properly implement the Bleichenbacher protection for export cipher suites. An attacker could use a SSLv2 server using OpenSSL as a Bleichenbacher oracle.

Take Action

Red Hat recommends that customers conduct a risk-based prioritization analysis of their affected systems and immediately apply available patches to remediate the issue. Rebooting the system after updating is the safest way to ensure all affected services use the updated ssl library. If a reboot is not possible, restarting all network services that depend on openssl after applying the patches is required.

Updates for Affected Products

Product Package Advisory
Red Hat Enterprise Linux 4 - Extended Lifecycle Support* openssl-0.9.7a-43.23.el4 RHSA-2016:0306
Red Hat Enterprise Linux 5 openssl-0.9.8e-39.el5_11 RHSA-2016:0302
Red Hat Enterprise Linux 5.6 Long Life openssl-0.9.8e-12.el5_6.13 RHSA-2016:0304
Red Hat Enterprise Linux 5.9 Long Life openssl-0.9.8e-26.el5_9.5 RHSA-2016:0304
Red Hat Enterprise Linux 6 openssl-1.0.1e-42.el6_7.4 RHSA-2016:0301
Red Hat Enterprise Linux 6.2 Advanced Update Support** openssl-1.0.0-20.el6_2.8 RHSA-2016:0303
Red Hat Enterprise Linux 6.4 Advanced Update Support** openssl-1.0.0-27.el6_4.5 RHSA-2016:0303
Red Hat Enterprise Linux 6.5 Advanced Update Support** openssl-1.0.1e-16.el6_5.16 RHSA-2016:0303
Red Hat Enterprise Linux 6.6 Extended Update Support openssl-1.0.1e-30.el6_6.12 RHSA-2016:0305
Red Hat Enterprise Linux 7 openssl-1.0.1e-51.el7_2.4 RHSA-2016:0301
Red Hat Enterprise Linux 7.1 Extended Update Support openssl-1.0.1e-42.el7_1.10, openssl-1.0.1e-42.ael7b_1.10 RHSA-2016:0305
Red Hat Enterprise Linux 6 openssl098e-0.9.8e-20.el6_7.1 RHSA-2016:0372
Red Hat Enterprise Linux 7 openssl098e-0.9.8e-29.el7_2.3 RHSA-2016:0372
Red Hat JBoss Web Server 2 Operating System openssl RHSA-2016-0445
Red Hat JBoss Web Server 3 Operating System openssl RHSA-2016-0446
Red Hat JBoss Enterprise Application Platform 5.2 Operating System openssl Apply OS-RHSA above, Windows/Solaris Patch Pending
Red Hat JBoss Enterprise Application Platform 6.4 Operating System openssl RHSA-2016-0490

*An active ELS subscription is required for access to this patch in RHEL 4. Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active ELS subscription.

What is the Red Hat Enterprise Linux Extended Life Cycle Support Add-On (ELS)?

**An active AUS subscription is required for access to this patch in RHEL 6.X AUS.

35 Comments

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.

Current Customers and Partners

Log in for full access

Log In

When running the DROWN-test.sh The installed version of openssl-libs (package openssl-libs is not installed) is not vulnerable to DROWN. do I need a reboot after updating openssl to 7.4?

Hi Larry - we recommend that any time major packages like openssl is updated that the system gets rebooted. This will ensure all services will have access to the updated library.

Hi Larry a reboot is not required. You will need to restart any specific services providing secure communications, such as HTTPS (port 443), or secure email emails (995 - pop; 993 - imap, etc), or any other daemons or applications which provide secure connections which use the openssl libraries. If you are unsure then yes, rebooting guarantees to ensure all services are using the new version from installed RPMs vs in-memory copies. - If you have very specific questions please do open a support case to discuss private information.

Regards, Cliff.

The message as:

The installed version of openssl-libs (package openssl-libs is not installed) is not vulnerable to DROWN. 

is a script bug that will hopefully be resolved soon.

You need to restart services using OpenSSL - either individually or by rebooting the system - as suggested by Chris and Cliff above.

Thanks for the replies.

when I do rpm -qa |grep openssl the servers do not show any openssl-libs installed. therefore the script seems to be correct. [root@co-ds-mys-a02 ~]# rpm -qa |grep openssl openssl-1.0.1e-42.el6.x86_64 openssl-devel-1.0.1e-42.el6.x86_64 [root@co-ds-mys-a02 ~]# [root@co-ds-mys-a02 ~]# ./DROWN-test.sh

WARNING: The installed version of openssl (openssl-1.0.1e-42.el6) is vulnerable to the general DROWN attack and should be upgraded. See https://access.redhat.com/security/vulnerabilities/drown for more information. The installed version of openssl-libs (package openssl-libs is not installed) is not vulnerable to DROWN.

when i run rpm -qa |grep openssl on a server that I know has openssl-libs installed and run the script. the script that the openssl-lib are vulnerable.

rpm -qa |grep openssl openssl-1.0.1e-42.el7_1.9.x86_64 openssl-devel-1.0.1e-42.el7_1.9.x86_64 openssl-libs-1.0.1e-42.el7_1.9.x86_64

./DROWN-test.sh WARNING: The installed version of openssl (openssl-1.0.1e-42.el7_1.9) is vulnerable to the general DROWN attack and should be upgraded. See https://access.redhat.com/security/vulnerabilities/drown for more information. WARNING: The installed version of openssl-libs (openssl-libs-1.0.1e-42.el7_1.9) is out of date and may present a security risk. See https://access.redhat.com/security/vulnerabilities/drown for more information.

The openssl-libs package only exists on Red Hat Enterprise Linux 7. In older Red Hat Enterprise Linux versions, OpenSSL libraries are packaged in the openssl rpm. Updated script version should avoid reporting packages that are not installed to avoid confusion.

If my server behind Load Balancer, do i still update my openSSL?

You should update OpenSSL if the host accepts SSL/TLS connections.

If your load balancer terminates SSL/TLS connections and uses no encryption for connections to backend servers, you probably want to check and/or patch the load balancer first. If it only distributes TCP connections between backend servers without terminating SSL/TLS connections, you probably need to prioritize checking / fixing backend servers.

The exit code of the script is always 0 even if there is a problem found:

~ # ./DROWN-test.sh

WARNING: The installed version of openssl (openssl-1.0.1e-42.el6_7.2) is vulnerable to the general DROWN attack and should be upgraded. See https://access.redhat.com/security/vulnerabilities/drown for more information. The installed version of openssl-libs (package openssl-libs is not installed) is not vulnerable to DROWN.

~ # echo $? 0

The result & lib_result variables don't seem to keep their values outside of the while loop?

Yes, the exit code is incorrect for the reason you mention. Issue is expected to be corrected in the upcoming script update.

From wahre i can download DROWN-test.sh scripts

Diagnose tab tnoc

See the Diagnose as was pointed out in the previous reply, or go directly to the Red Hat Access Labs application for DROWN:

https://access.redhat.com/labs/drown/

DROWN-test.sh script is under the "Diagnose" tab.

Should packages not tested by script DROWN-test.sh (i.e. openssl-devel.x86_64 ) be updated?

You should upgrade all OpenSSL packages that are updated by the released errata. Actually, package dependencies should prevent you from updating only openssl / openssl-libs and not update openssl-devel at the same time, without forcing package manager to ignore dependencies.

Ok, thank you very much !

Script 1.1 seems to be working.

When I run a yum update I am not seeing the recommended openssl package version. It had "openssl-1.0.1e-42.el6_7.2" as the most recent version available. Is this a yum repo setting I need to modify? I am running RedHat 6.7

Thank you

Stephen, If your system gets updates from a local Red Hat Satellite, that Satellite needs to synchronize with the RHN repositories to get the latest packages. Our Satellite server syncs every night and picked up the RHEL 6.7 "openssl-1.0.1e-42.el6_7.4" package last night. Hope this helps.

Thank you Islam Qoran, I have now able to update to newest release.

No special repository settings should be required. As noted in the previous reply, use of Red Hat Satellite may add some delay into when updated packages are available to your systems. You may also try to force expiry of the cached repository metadata (e.g. using yum clean expire-cache) to ensure your systems has up-to-date view of the repositories.

For further troubleshooting, please get in touch with Red Hat Support.

It seems I'm unable to authenticate the script against pgp.mit.edu. What gives ?

c:>ping pgp.mit.edu

Pinging cryptonomicon.mit.edu [18.9.60.141] with 32 bytes of data:

Request timed out.

Ping statistics for 18.9.60.141: Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

From one of my RHEL hosts

$> ping 18.9.60.141

PING 18.9.60.141 (18.9.60.141) 56(84) bytes of data.

^C

--- 18.9.60.141 ping statistics ---

19 packets transmitted, 0 received, 100% packet loss, time 18590ms

Kurt, I'm not sure you're supposed to be able to ping it (ICMP packets might be dropped for that host/network). I'm not able to ping either.

As described in the Diagnose Tab, the steps to verify are:

$ gpg --keyserver pgp.mit.edu --recv 8366b0d9

$ gpg --verify DROWN-test.sh.asc DROWN-test.sh

Hope this helps.

If you can't access MIT PGP key server, you can manually download the key from Red Hat site. The DROWN Labs page already points to the Product Signing (GPG) Keys page, where you can find the following link for the 8366b0d9 key:

https://www.redhat.com/security/8366b0d9.txt

Download it to your system, after than you can import it and the verify DROWN-test.sh script signature:

$ gpg --import 8366b0d9.txt
$ gpg --verify DROWN-test.sh.asc DROWN-test.sh

For RHEL 6, is openssl098e.x86_64 vulnerable? If so, when will a corrective errata be available?

Thanks

Robert, In the meantime, there is a Diagnose Tab in this article that links to https://access.redhat.com/labs/drown/. You might get a faster response to your question if you follow the steps and execute the DROWN-test.sh script.

I don't have any RHEL 6 systems with [openssl098e], only [openssl-1.0.1e]. Hope this helps.

The DROWN-test.sh script does not list openssl098e RPM as vulnerable for RHEL 6. I am skeptical because it is vulnerable in RHEL 5. I will simply open a support ticket with Red Hat.

Thanks

Hi Robert, as noted on page https://access.redhat.com/security/cve/CVE-2016-0800 - this package is effected, with no current plans to provide a fix (subject to change). Please do contact the Red Hat Product Security team at the address linked at the bottom of that page to follow up - https://access.redhat.com/security/team/contact/.
Regards, Cliff

Are RHEL6 package openssl098e-0.9.8e-18.el6_5.2.x86_64 and RHEL7 package openssl098e-0.9.8e-29.el7_0.2.x86_64 vulnerable?

Updates for openssl098e packages in Red Hat Enterprise Linux 6 and 7 were released via RHSA-2016:0372.

I have installed Oracle Linux 6.5 with openssl-1.0.1e-30.el6.4.0.1.x86_64 installed. I've ran:

./DROWN-test.sh The installed version of openssl (openssl-1.0.1e-30.el6.4.0.1.x86_64) is not known to be vulnerable to DROWN.

However, as I can see from DROWN-test.sh the following (newer!) versions of openssl are affected:

RHEL6

... "openssl-1.0.1e-30.el6" "openssl-1.0.1e-30.el6_6.2" "openssl-1.0.1e-30.el6_6.4" "openssl-1.0.1e-30.el6_6.5"

Please let me know if openssl-1.0.1e-30.el6.4.0.1.x86_64 is really affected or not?

Thank you.

The DROWN-test.sh script only supports Red Hat Enterprise Linux packages. For any questions about packages form different distributions, you need to contact the respective vendor.

How can I find is there any dependency package required to update the openssl package as I going to update from the downloaded RPM package

Updates above did not add any new dependency to the openssl packages compared to their previous versions.

For further assistance with having these updates deployed, please get in touch with Red Hat Support.