2

The OWASP dependency-check project has an open ticket (#561) that I am unable to reproduce or figure out exactly what is going on. On some systems using OpenJDK HTTPS connections to the NVD CVE Data Feed (https://nvd.nist.gov/download/nvdcve-Modified.xml.gz) fail. Specifically, they fail with a java.net.SocketException: Connection reset. I have been unable to reproduce the issue on any system I own - any of the JRE/JDK installs seem to work on my systems (ibm, oracle, open jdk).

A gist of the SSL Debug log from a system for which the TLS connection fails can be found here. Can anyone shed some light as to why the HTTPS download is failing for some installations? When people have had an issue with openJDK and they install Oracle JDK the download works.

Thanks!

--jeremy

user1995422
  • 220
  • 1
  • 3
  • 13
  • Out of curiosity - how did you get the linked in SSL log? (Side remark: thanks for the remarkable work you put in in dep. check project.) –  Dec 05 '17 at 10:17

1 Answers1

4

According to ssllabs test the site nvd.nist.gov used for downloading only supports TLS1.1 and TLS1.2 with only a few ciphers:

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)

Comparing this information with the log gist you linked you can see that for every mentioned cipher suite Java reports "Ignoring unavailable cipher suite".

Therefore the connection will always fail, because server and client have no cipher in common they can use to encrypt the TLS connection.

From my point of view I would assume that the used OpenJDK was compiled without Elliptic curve support or has an invalid configuration that prohibits the usage of those ciphers.

Hence it is configuration or build problem of the used OpenJDK version.

Edit: May be the following question is related:

Community
  • 1
  • 1
Robert
  • 39,162
  • 17
  • 99
  • 152