8u131 & 8u121 on Alpine Has TLS negotiation Issues

[DaveWK]

I am not sure if this is an issue with openjdk, alpine, docker, or the implementation of the 3 combined, however I wanted to check and see if anyone else had seen an InvalidAlgorithmParameterException when attempting to use TLS connections between java containers; my issue is the same as the one described here: http://stackoverflow.com/questions/43067340/java-security-invalidalgorithmparameterexception-null

Not sure if openjdk is being packaged incorrectly by alpine, or if theres an issue with the defaults that were introduced in 8u121. I do not see this issue in 8u111

[roadmapper]

Interesting, when we tried to use 8u121 (Alpine 3.5) in our Tomcat 8 containers we saw similar problems, but we weren't able to find a resolution; we switched to using OpenJDK 8u111 (which is Alpine 3.4) and building a Tomcat image manually for now until things are sorted out.

Maybe the certificate provider is a problem but it might also be the switch to libressl in Alpine 3.5 broke something. This issue is still open on the docker official-images repo.

[shatil]

@Dklotz-Circle, can I trouble you to update the title to mention that it's still a bug in the current release?

Similar issue impacts current 8-jre-alpine (currently 8u131-jre-alpine):

# java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (IcedTea 3.4.0) (Alpine 8.131.11-r1)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

curl works fine from another Alpine Linux container, macOS Sierra, and Chrome has no issue beyond the self-signed SSL cert. But, from Ubuntu 14.04, openssl causes curl to fail:

$ curl -Ikv https://172.28.128.14/status
* Hostname was NOT found in DNS cache
*   Trying 172.28.128.14...
* Connected to 172.28.128.14 (172.28.128.14) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS alert, Server hello (2):
* error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
* Closing connection 0
curl: (35) error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error

Versus 8-jre (currently 8u131-jre built from Debian Jessie):

# java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-1~bpo8+1-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

Result from same curl:

$ curl -Ikv https://172.28.128.1/status
* Hostname was NOT found in DNS cache
*   Trying 172.28.128.1...
* Connected to 172.28.128.1 (172.28.128.1) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-RSA-AES256-GCM-SHA384
...

I don't know where the bug ultimately lies, but if you point me, I will go file bug reports wherever needed.

[shatil]

This appears to be an issue in Alpine Linux 3.6 running openjdk8-jre. I was able to reproduce the issue I saw running in8-jre-alpine using this Dockerfile:

FROM alpine:3.6
RUN apk --no-cache add openjdk8-jre

(Which is no surprise considering this project's relevant Dockerfile does exactly that....)

$ sudo docker exec -it docker_svc_1 java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (IcedTea 3.4.0) (Alpine 8.131.11-r1)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

I filed a bug in Alpine Linux for this: https://bugs.alpinelinux.org/issues/7404

[shatil]

The last version this works fine on is Alpine Linux 3.4, whose latest was openjdk8-jre u111, which appears not to be an IcedTea edition?

$ sudo docker exec -it docker_svc_1 java -version
openjdk version "1.8.0_111-internal"
OpenJDK Runtime Environment (build 1.8.0_111-internal-alpine-r0-b14)
OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)

(Same curl).

[shatil]

Using the script from "How do I list the SSL/TLS cipher suites a particular website offers?", I discovered OpenJDK 8 u131 on Alpine 3.6 dropped support for all of Mozilla's "Modern" cipher suites.

Left is 8-jre-alpine and right is 8-jre (the Jessie-running one).

Compare Alpine 3.4's (whose cipher suites for the "Modern" list are identical to the current 8-jre):

Obtaining cipher list from OpenSSL 1.0.1f 6 Jan 2014.
Testing ECDHE-ECDSA-AES256-GCM-SHA384...NO (sslv3 alert handshake failure)
Testing ECDHE-RSA-AES256-GCM-SHA384...YES
Testing ECDHE-ECDSA-CHACHA20-POLY1305...NO (no cipher match)
Testing ECDHE-RSA-CHACHA20-POLY1305...NO (no cipher match)
Testing ECDHE-ECDSA-AES128-GCM-SHA256...NO (sslv3 alert handshake failure)
Testing ECDHE-RSA-AES128-GCM-SHA256...YES
Testing ECDHE-ECDSA-AES256-SHA384...NO (sslv3 alert handshake failure)
Testing ECDHE-RSA-AES256-SHA384...YES
Testing ECDHE-ECDSA-AES128-SHA256...NO (sslv3 alert handshake failure)
Testing ECDHE-RSA-AES128-SHA256...YES

To 8-jre:

Obtaining cipher list from OpenSSL 1.0.1f 6 Jan 2014.
Testing ECDHE-ECDSA-AES256-GCM-SHA384...NO (sslv3 alert handshake failure)
Testing ECDHE-RSA-AES256-GCM-SHA384...YES
Testing ECDHE-ECDSA-CHACHA20-POLY1305...NO (no cipher match)
Testing ECDHE-RSA-CHACHA20-POLY1305...NO (no cipher match)
Testing ECDHE-ECDSA-AES128-GCM-SHA256...NO (sslv3 alert handshake failure)
Testing ECDHE-RSA-AES128-GCM-SHA256...YES
Testing ECDHE-ECDSA-AES256-SHA384...NO (sslv3 alert handshake failure)
Testing ECDHE-RSA-AES256-SHA384...YES
Testing ECDHE-ECDSA-AES128-SHA256...NO (sslv3 alert handshake failure)
Testing ECDHE-RSA-AES128-SHA256...YES

Whereas Alpine 3.6's is entirely different:

Obtaining cipher list from OpenSSL 1.0.1f 6 Jan 2014.
Testing ECDHE-ECDSA-AES256-GCM-SHA384...NO (sslv3 alert handshake failure)
Testing ECDHE-RSA-AES256-GCM-SHA384...NO (tlsv1 alert internal error)
Testing ECDHE-ECDSA-CHACHA20-POLY1305...NO (no cipher match)
Testing ECDHE-RSA-CHACHA20-POLY1305...NO (no cipher match)
Testing ECDHE-ECDSA-AES128-GCM-SHA256...NO (sslv3 alert handshake failure)
Testing ECDHE-RSA-AES128-GCM-SHA256...NO (tlsv1 alert internal error)
Testing ECDHE-ECDSA-AES256-SHA384...NO (sslv3 alert handshake failure)
Testing ECDHE-RSA-AES256-SHA384...NO (tlsv1 alert internal error)
Testing ECDHE-ECDSA-AES128-SHA256...NO (sslv3 alert handshake failure)
Testing ECDHE-RSA-AES128-SHA256...NO (tlsv1 alert internal error)

These are the cipher suites supported by 8-jre-alpine (14 total):

Testing DHE-RSA-AES256-GCM-SHA384...YES
Testing DHE-RSA-AES256-SHA256...YES
Testing DHE-RSA-AES256-SHA...YES
Testing AES256-GCM-SHA384...YES
Testing AES256-SHA256...YES
Testing AES256-SHA...YES
Testing EDH-RSA-DES-CBC3-SHA...YES
Testing DES-CBC3-SHA...YES
Testing DHE-RSA-AES128-GCM-SHA256...YES
Testing DHE-RSA-AES128-SHA256...YES
Testing DHE-RSA-AES128-SHA...YES
Testing AES128-GCM-SHA256...YES
Testing AES128-SHA256...YES
Testing AES128-SHA...YES

Whereas 8-jre supports 21:

Testing ECDHE-RSA-AES256-GCM-SHA384...YES
Testing ECDHE-RSA-AES256-SHA384...YES
Testing ECDHE-RSA-AES256-SHA...YES
Testing DHE-RSA-AES256-GCM-SHA384...YES
Testing DHE-RSA-AES256-SHA256...YES
Testing DHE-RSA-AES256-SHA...YES
Testing AES256-GCM-SHA384...YES
Testing AES256-SHA256...YES
Testing AES256-SHA...YES
Testing ECDHE-RSA-DES-CBC3-SHA...YES
Testing EDH-RSA-DES-CBC3-SHA...YES
Testing DES-CBC3-SHA...YES
Testing ECDHE-RSA-AES128-GCM-SHA256...YES
Testing ECDHE-RSA-AES128-SHA256...YES
Testing ECDHE-RSA-AES128-SHA...YES
Testing DHE-RSA-AES128-GCM-SHA256...YES
Testing DHE-RSA-AES128-SHA256...YES
Testing DHE-RSA-AES128-SHA...YES
Testing AES128-GCM-SHA256...YES
Testing AES128-SHA256...YES
Testing AES128-SHA...YES

We should definitely be aiming for parity there, and not ignoring an entire branch of cipher suites.... I'm guessing there's a flag for the ECDHE family that was accidentally toggled.

[yosifkit]

Thanks @shatil! Hopefully that bug report to Alpine can fix the problem.

[shatil]

So... it appears the Alpine 3.6's OpenJDK does include SunEC like the --enable-sunec line in APKBUILD says:

# find /usr/lib/jvm -iname '*sunec*'
/usr/lib/jvm/java-1.8-openjdk/jre/lib/ext/sunec.jar
/usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/libsunec.so

Using Atlassian's "List ciphers used by JVM" produces identical results for the Jessie- and Alpine-3.6-based Docker images.

import java.util.Iterator;
import java.util.Map;
import java.util.TreeMap;
import javax.net.ssl.SSLServerSocketFactory;

public class Ciphers
{
    public static void main(String[] args)
        throws Exception
    {
        SSLServerSocketFactory ssf = (SSLServerSocketFactory)SSLServerSocketFactory.getDefault();

        String[] defaultCiphers = ssf.getDefaultCipherSuites();
        String[] availableCiphers = ssf.getSupportedCipherSuites();

        TreeMap ciphers = new TreeMap();

        for(int i=0; i<availableCiphers.length; ++i )
            ciphers.put(availableCiphers[i], Boolean.FALSE);

        for(int i=0; i<defaultCiphers.length; ++i )
            ciphers.put(defaultCiphers[i], Boolean.TRUE);

        System.out.println("Default\tCipher");
        for(Iterator i = ciphers.entrySet().iterator(); i.hasNext(); ) {
            Map.Entry cipher=(Map.Entry)i.next();

            if(Boolean.TRUE.equals(cipher.getValue()))
                System.out.print('*');
            else
                System.out.print(' ');

            System.out.print('\t');
            System.out.println(cipher.getKey());
        }
    }
}

Which you run like:

javac Ciphers.java
java Ciphers

I still don't get why the ECDH family is disabled by default on Alpine when my application serves HTTPS, whereas on the Jessie-built image, they're enabled.

[shatil]

I see no progress from the bug report I filed in upstream Alpine. I posted to their forum, but I seem to be the only person ever looking at the page.

Is the upstream project dead? Or just overwhelmed and/or understaffed? I'm using Alpine because of its slimness (some deployments I manage have prohibitive bandwidth restrictions).

[tianon]

Alpine Linux is definitely not dead, but the maintainer of that package (or other folks who help triage/assign bugs) are likely short on time.

[shatil]

@tianon, I see.

I ran my application with -Djavax.net.debug=ssl:handshake:verbose to see its handshake logs and added -Djdk.tls.client.protocols=TLSv1,TLSv1.1,TLSv1.2 in a vain attempt to enable ciphers for TLSv1:

Using SSLEngineImpl.
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
New I/O worker #4, READ: TLSv1 Handshake, length = 286
*** ClientHello, TLSv1.2
RandomCookie:  GMT: 96205702 bytes = { 16, 134, 158, 119, 151, 61, 30, 93, 113, 118, 29, 32, 47, 105, 45, 47, 214, 42, 203, 28, 81, 230, 137, 227, 192, 0, 197, 102 }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA, TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_CAMELLIA_256_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_SEED_CBC_SHA, TLS_DHE_DSS_WITH_SEED_CBC_SHA, TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA, TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_SEED_CBC_SHA, TLS_RSA_WITH_CAMELLIA_128_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Extension server_name, server_name: [type=host_name (0), value=localhost]
Extension ec_point_formats, formats: [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]
Extension elliptic_curves, curve names: {sect571r1, sect571k1, secp521r1, sect409k1, sect409r1, secp384r1, sect283k1, sect283r1, secp256k1, secp256r1, sect239k1, sect233k1, sect233r1, secp224k1, secp224r1, sect193r1, sect193r2, secp192k1, secp192r1, sect163k1, sect163r1, sect163r2, secp160k1, secp160r1, secp160r2}
Extension signature_algorithms, signature_algorithms: SHA512withRSA, Unknown (hash:0x6, signature:0x2), SHA512withECDSA, SHA384withRSA, Unknown (hash:0x5, signature:0x2), SHA384withECDSA, SHA256withRSA, SHA256withDSA, SHA256withECDSA, SHA224withRSA, SHA224withDSA, SHA224withECDSA, SHA1withRSA, SHA1withDSA, SHA1withECDSA
Unsupported extension type_15, data: 01
***
%% Initialized:  [Session-16, SSL_NULL_WITH_NULL_NULL]
New I/O worker #4, fatal error: 80: problem unwrapping net record
java.lang.RuntimeException: java.security.InvalidAlgorithmParameterException
%% Invalidated:  [Session-16, SSL_NULL_WITH_NULL_NULL]
New I/O worker #4, SEND TLSv1.2 ALERT:  fatal, description = internal_error
New I/O worker #4, WRITE: TLSv1.2 Alert, length = 2
New I/O worker #4, called closeOutbound()
New I/O worker #4, closeOutboundInternal()

I tried with Oracle's JCE Unlimited Strength Policy, as well, to no avail.

[shatil]

@gnu-andrew mentioned elsewhere that OpenJDK may report what it (through SunEC) supports, rather than what NSS supports, which on RHEL provides the curves' libraries for OpenJDK:

• Bug 1022017: "OpenJDK should report the elliptic curves supported by NSS, not the SunEC library"
• Bug 1348525: "OpenJDK should report the elliptic curves supported by NSS, not the SunEC library"

[shatil]

@Dklotz-Circle, can you try JVM argument -Djdk.tls.namedGroups='secp256r1, secp384r1, secp521r1' as a temporary workaround?

Train of thought:

1. Bugzilla links above -> Andrew's commit: http://icedtea.classpath.org//hg/icedtea?cmd=changeset;node=04327567ef0a
2. OpenJDK source: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/9c692f857417/src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java
3. That JVM System Property since OpenJDK doesn't have @gnu-andrew's change there

Result with server-side, but no client-side, modifications:

Using SSLEngineImpl.
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
New I/O worker #3, READ: TLSv1 Handshake, length = 286
*** ClientHello, TLSv1.2
RandomCookie:  GMT: 842831962 bytes = { 36, 243, 53, 81, 234, 254, 206, 242, 166, 22, 128, 27, 146, 59, 220, 59, 77, 117, 165, 54, 9, 122, 8, 65, 34, 152, 101, 87 }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_E
CDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, T
LS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA, TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA,
 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_25
6_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_CAMELLIA_256_CBC_SHA, TL
S_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, T
LS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SH
A256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_12
8_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_SEED_CBC
_SHA, TLS_DHE_DSS_WITH_SEED_CBC_SHA, TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA, TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_
GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_12
8_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_SEED_CBC_SHA, TLS_RSA_WITH_CAMELLIA_128_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Extension server_name, server_name: [type=host_name (0), value=localhost]
Extension ec_point_formats, formats: [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]
Extension elliptic_curves, curve names: {sect571r1, sect571k1, secp521r1, sect409k1, sect409r1, secp384r1, sect283k1, sect283r1, secp256k1, secp256r1, sect239k1, sect233k1, sect233r
1, secp224k1, secp224r1, sect193r1, sect193r2, secp192k1, secp192r1, sect163k1, sect163r1, sect163r2, secp160k1, secp160r1, secp160r2}
Extension signature_algorithms, signature_algorithms: SHA512withRSA, Unknown (hash:0x6, signature:0x2), SHA512withECDSA, SHA384withRSA, Unknown (hash:0x5, signature:0x2), SHA384with
ECDSA, SHA256withRSA, SHA256withDSA, SHA256withECDSA, SHA224withRSA, SHA224withDSA, SHA224withECDSA, SHA1withRSA, SHA1withDSA, SHA1withECDSA
Unsupported extension type_15, data: 01
***
%% Initialized:  [Session-21, SSL_NULL_WITH_NULL_NULL]
Standard ciphersuite chosen: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
%% Negotiating:  [Session-21, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384]
*** ServerHello, TLSv1.2
RandomCookie:  GMT: 1497397670 bytes = { 150, 147, 90, 137, 133, 173, 124, 97, 47, 28, 126, 180, 122, 67, 11, 245, 178, 181, 221, 169, 87, 141, 216, 255, 245, 251, 210, 83 }
Session ID:  {89, 64, 122, 166, 216, 139, 22, 251, 122, 73, 68, 221, 129, 37, 195, 203, 38, 52, 11, 35, 71, 191, 222, 237, 118, 34, 243, 2, 115, 201, 3, 139}
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
Cipher suite:  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
*** Certificate chain
...

curl on Ubuntu 14.04 works:

# curl -vIk https://localhost:443/eping
* Hostname was NOT found in DNS cache
*   Trying ::1...
* Connected to localhost (::1) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-RSA-AES256-GCM-SHA384
...

Simple solution might be patching openjdk8 in Alpine Linux like:

diff --git a/SupportedEllipticCurvesExtension.java b/SupportedEllipticCurvesExtension.java
index 59f4b74..75695c6 100644
--- a/SupportedEllipticCurvesExtension.java
+++ b/SupportedEllipticCurvesExtension.java
@@ -183,6 +183,10 @@ final class SupportedEllipticCurvesExtension extends HelloExtension {
                 };
             }

+            // NSS currently only supports these three NIST curves
+            ids = new int[] {
+                23, 24, 25,
+            };
             idList = new ArrayList<>(ids.length);
             for (int curveId : ids) {
                 if (isAvailableCurve(curveId)) {

[jirutka]

Is the upstream project dead?

No, it's definitely not dead, just "understaffed". However, the forum is more or less dead, IMO it's redundant and it'd be better if we close it.

I've already looked at this issue, but don't know how to fix it. It's not about setting some configure option, all related options are already enabled.

Have anyone tried to reproduce this on Fedora?

[shatil]

@jirutka Fedora applies a more aggressive version of the patch I mentioned: http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/pr1834-rh1022017.patch

Curiously, Debian does not apply that patch....