Bug 1346460 - Using -Djavax.net.debug=ssl,handshake with clients that send EC curve extension in ClientHello gives java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available
Using -Djavax.net.debug=ssl,handshake with clients that send EC curve extensi...
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: java-1.8.0-openjdk (Show other bugs)
Unspecified Unspecified
high Severity unspecified
: rc
: ---
Assigned To: Andrew John Hughes
Lukas Zachar
: ZStream
Depends On:
Blocks: 1365618 1391684
  Show dependency treegraph
Reported: 2016-06-14 17:39 EDT by Chris Dolphy
Modified: 2016-11-03 18:57 EDT (History)
4 users (show)

See Also:
Fixed In Version: java-1.8.0-openjdk-
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1365618 1391684 (view as bug list)
Last Closed: 2016-11-03 18:57:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Icedtea Bugzilla 3083 None None None 2016-07-04 13:47 EDT

  None (edit)
Description Chris Dolphy 2016-06-14 17:39:42 EDT
Description of problem:
Using javax.net.debug=ssl,handshake with clients that send EC curve extension in ClientHello gives java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available.

I used byteman to get the following stacktrace:

java.lang.RuntimeException: java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available
   at sun.security.util.ECUtil.getECParameters(ECUtil.java:100)
   at sun.security.util.ECUtil.getECParameterSpec(ECUtil.java:149)
   at sun.security.ssl.JsseJce.getECParameterSpec(JsseJce.java:385)
   at sun.security.ssl.SupportedEllipticCurvesExtension.toString(SupportedEllipticCurvesExtension.java:127)
   at sun.security.ssl.HelloExtensions.print(HelloExtensions.java:150)
   at sun.security.ssl.HandshakeMessage$ClientHello.print(HandshakeMessage.java:323)
   at sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:340)
   at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:221)
   at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
   at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
   at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
   at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
   at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
   at sun.security.ssl.SSLSocketImpl.getSession(SSLSocketImpl.java:2267)
   at org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:201)
   at org.apache.tomcat.util.net.JIoEndpoint.setSocketOptions(JIoEndpoint.java:1114)
   at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
   at java.lang.Thread.run(Thread.java:745)
Caused by: java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available
   at sun.security.jca.GetInstance.getInstance(GetInstance.java:159)
   at java.security.Security.getImpl(Security.java:695)
   at java.security.AlgorithmParameters.getInstance(AlgorithmParameters.java:146)
   at sun.security.util.ECUtil.getECParameters(ECUtil.java:98)
   ... 17 more

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create a SSL server in Java (originally identified in with Red Hat JBoss EAP), but any Java SSL listener should get the error
2. Enable SSL debug logging with -Djavax.net.debug=ssl,handshake system property.
3. Connect with a TLS/SSL client that sends the EC curve in the ClientHello like most browsers.

Actual results:
Throws java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available.

Expected results:
Successful handshake.

Additional info:
This occurs only on RHEL Java 1.8 which currently has SunEC disabled.  The issue is that the SSL debugging logging attempts to use the EC provider to log the curves in the ClientHello and get the NoSuchAlgoException.
Comment 2 Andrew John Hughes 2016-06-21 21:10:04 EDT
Replicated this on OpenJDK 8 with the SunEC and PKCS11 providers disabled. It seems to be a regression caused by "7194075: Various classes of sunec.jar are duplicated in rt.jar", as it doesn't occur with OpenJDK 7.

The methods in ECUtil throw a RuntimeException if they can't get an EC provider. Given that an EC provider is optional, they should instead return null. This is especially true as the same code seems happy enough to swallow exceptions about invalid parameters and return null (i.e. calling code expects null as failure anyway).

To replicate:

1. Start an OpenJDK TLSv2 server with all EC providers disabled and -Djavax.net.debug=ssl,handshake
2. Connect to it with a client that supports ECC e.g.
openssl s_client -connect <host>:<port>

It will crash when trying to print the curve names:

Extension ec_point_formats, formats: [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]
main, handling exception: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available
main, SEND TLSv1.2 ALERT:  fatal, description = internal_error

The result should be:

Extension ec_point_formats, formats: [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]
Extension elliptic_curves, curve names: {secp521r1, secp384r1, secp256r1}
...connection continues
Comment 5 Andrew John Hughes 2016-07-04 21:19:37 EDT
This is only present in RHEL 7.3 if the SunEC provider is disabled by the user. We really need to fix this in 7.2, where there is no SunEC provider and this bug gets hit when debugging SSL connections.
Comment 10 Andrew John Hughes 2016-10-26 21:58:22 EDT
In line with comment #5, there is no immediate need for this in RHEL 6 as RHEL 6.8 already has the SunEC provider and so will only hit this if SunEC is manually disabled. 

We can look at fixing it for RHEL 6.9.
Comment 12 Andrew John Hughes 2016-11-03 14:44:22 EDT
I've created bug 1391684 for fixing this on RHEL 6.
Comment 13 errata-xmlrpc 2016-11-03 18:57:11 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.