Bug 1346460

Summary: Using -Djavax.net.debug=ssl,handshake with clients that send EC curve extension in ClientHello gives java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available
Product: Red Hat Enterprise Linux 7 Reporter: Chris Dolphy <cdolphy>
Component: java-1.8.0-openjdkAssignee: Andrew John Hughes <ahughes>
Status: CLOSED ERRATA QA Contact: Lukáš Zachar <lzachar>
Severity: unspecified Docs Contact:
Priority: high    
Version: 7.2CC: ahughes, dbhole, jvanek, pbhoot
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: java-1.8.0-openjdk-1.8.0.101-2.b13.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1365618 1391684 (view as bug list) Environment:
Last Closed: 2016-11-03 22:57:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1365618, 1391684    

Description Chris Dolphy 2016-06-14 21:39:42 UTC
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):
java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64

How reproducible:
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-22 01:10:04 UTC
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-05 01:19:37 UTC
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-27 01:58:22 UTC
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 18:44:22 UTC
I've created bug 1391684 for fixing this on RHEL 6.

Comment 13 errata-xmlrpc 2016-11-03 22:57:11 UTC
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.

https://rhn.redhat.com/errata/RHEA-2016-2139.html