This is because you are using Conscrypt and not the Java Crypto module. Java 
security setting will have no impact on conscrypt. All of my previous 
suggestions were centered around Java/OpenJDK crypto as that is (at least on 
OpenJDK 8) the Jetty default.


Gregory Young

From: [email protected] <[email protected]> On 
Behalf Of Glen Peterson
Sent: October 18, 2019 10:30 AM
To: JETTY user mailing list <[email protected]>
Subject: Re: [jetty-users] Supporting strong ciphers in IE11/Win7 (and 8.1)

1. enable "unlimited strength ciphers" in the Java security config.

I think I'm good using OpenJDK, but I checked:
$ echo $JAVA_HOME
/usr/lib/jvm/java-11-openjdk-amd64

$ ls -l /usr/lib/jvm/java-11-openjdk-amd64/conf/security/
total 4
lrwxrwxrwx 1 root root   41 Jul 18 14:21 java.policy -> 
/etc/java-11-openjdk/security/java.policy
lrwxrwxrwx 1 root root   43 Jul 18 14:21 java.security -> 
/etc/java-11-openjdk/security/java.security
lrwxrwxrwx 1 root root   37 Jul 18 14:21 nss.cfg -> 
/etc/java-11-openjdk/security/nss.cfg
drwxr-xr-x 4 root root 4096 Aug  1 07:59 policy

vim /etc/java-11-openjdk/security/java.security
...
crypto.policy=unlimited
...
# Curious about this:
ssl.KeyManagerFactory.algorithm=SunX509
ssl.TrustManagerFactory.algorithm=PKIX

I'm curious about the SunX509.  I do *not* set a keyManagerFactory (I'm a 
server, not a client, and don't require client-side certificates).  But when 
Jetty starts up, I can see the following debugging info which I've just been 
ignoring:

Unable to get KeyManagerFactory instance for algorithm [SunX509] on provider 
[Conscrypt], using default

java.security.NoSuchAlgorithmException: no such algorithm: SunX509 for provider 
Conscrypt
at java.base/sun.security.jca.GetInstance.getService(GetInstance.java:87)
at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:206)
at 
java.base/javax.net.ssl.KeyManagerFactory.getInstance(KeyManagerFactory.java:195)
at 
org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagerFactoryInstance(SslContextFactory.java:1817)
at 
org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1275)
at org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:416)
at 
org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:287)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
at 
org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:92)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
at 
org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:320)
at 
org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:81)
at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:231)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at org.eclipse.jetty.server.Server.doStart(Server.java:385)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at org.organicdesign.classVsJar.ClazzVsJarKt.main(ClazzVsJar.kt:288)


2. for the "TLS_ECDHE_ECDSA_WITH_AES_*" ciphers to be available...

TLS_ECDHE_RSA_WITH_AES_* ciphers show up as available in Jetty debugging info 
and are agreed upon by nmap (output of both are shown in my original message).  
I spent an hour messing around with my keystore anyway, but nothing good 
resulted.

3. Your Java or Jetty config have DHE ciphers disabled. I think the default 
OpenJDK config has DHE less than 2048 bits disabled if I recall correctly.

Both TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and 
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 are showing in Jetty's "available ciphers" 
debugging info, but are not available when I try to connect with nmap.

I noticed that the 4 strong ciphers that IE11/Win7 is said to support are 
supported by openssl, but it has its own name for them.  Not sure if that could 
have anything to do with it.  It looks in the TLS spec like they are identified 
by some two-byte hex code and not a human-readable name, but I don't know:
$ openssl ciphers -stdname
...
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 
Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
...
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 
Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
...
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH   
    Au=RSA  Enc=AESGCM(256) Mac=AEAD
...
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH   
    Au=RSA  Enc=AESGCM(128) Mac=AEAD
...

Simone: I'll respond in a bit.

On Wed, Oct 16, 2019 at 3:53 PM Young, Gregory 
<[email protected]<mailto:[email protected]>> wrote:
Probably one of 3 issues going on:

1. You need to enable "unlimited strength ciphers" in the Java security config.
2. for the "TLS_ECDHE_ECDSA_WITH_AES_*" ciphers to be available, you need to 
add a newer ECDSA signed SSL certificate to the keystore (you can run both RSA 
and ECDSA signed certs in parallel on the same Jetty instance).
3. Your Java or Jetty config have DHE ciphers disabled. I think the default 
OpenJDK config has DHE less than 2048 bits disabled if I recall correctly.


Gregory Young


-----Original Message-----
From: [email protected]<mailto:[email protected]> 
<[email protected]<mailto:[email protected]>> On 
Behalf Of Simone Bordet
Sent: October 16, 2019 4:24 AM
To: JETTY user mailing list 
<[email protected]<mailto:[email protected]>>
Subject: Re: [jetty-users] Supporting strong ciphers in IE11/Win7 (and 8.1)

Hi,

On Wed, Oct 16, 2019 at 12:03 AM Glen Peterson 
<[email protected]<mailto:[email protected]>> wrote:
>
> According to Qualys SSL Labs, IE 11 on on Windows 7 and 8.1 only works with 
> max TLS 1.2 and only supports the following 4 secure forward secrecy ciphers:
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
> Source:
> https://dev.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&pla
> tform=Win%207&key=143
>
> When I run nmap, those ciphers don't show up (SSL Labs reports the same):
> $ nmap --script ssl-enum-ciphers -p 8443 myDomain.com
>
> Starting Nmap 7.60 ( https://nmap.org ) at 2019-10-15 17:43 EDT Nmap
> scan report for myDomain.com (127.0.0.1) Host is up (0.000056s
> latency).
> rDNS record for 127.0.0.1<http://127.0.0.1>: localhost
>
> PORT     STATE SERVICE
> 8443/tcp open  https-alt
> | ssl-enum-ciphers:
> |   TLSv1.2:
> |     ciphers:
> |       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
> |       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
> |       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (rsa 2048) - A
> |     compressors:
> |       NULL
> |     cipher preference: server
> |_  least strength: A
>
> Nmap done: 1 IP address (1 host up) scanned in 0.30 seconds
>
>
>
> Jetty lists those ciphers as enabled:
>
> |  += SslConnectionFactory@6dbb137d{SSL->alpn} - STARTED  |  +=
> | 
> Server@5f058f00[provider=Conscrypt,keyStore=file:///home/folder/dev/etc/keystore,trustStore=null]
>  - STARTED
> |  |     +> trustAll=false
> |  |     +> Protocol Selections
> |  |     |  +> Enabled size=4
> |  |     |  |  +> TLSv1
> |  |     |  |  +> TLSv1.1
> |  |     |  |  +> TLSv1.2
> |  |     |  |  +> TLSv1.3
> |  |     |  +> Disabled size=2
> |  |     |     +> SSLv2Hello - ConfigExcluded:'SSLv2Hello' JVM:disabled
> |  |     |     +> SSLv3 - ConfigExcluded:'SSLv3' JVM:disabled
> |  |     +> Cipher Suite Selections
> |  |        +> Enabled size=27
> |  |        |  +> TLS_AES_128_GCM_SHA256
> |  |        |  +> TLS_AES_256_GCM_SHA384
> |  |        |  +> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
> |  |        |  +> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
> |  |        |  +> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
> |  |        |  +> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
> |  |        |  +> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
> |  |        |  +> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> |  |        |  +> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
> |  |        |  +> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> |  |        |  +> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
> |  |        |  +> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
> |  |        |  +> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> |  |        |  +> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
> |  |        |  +> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
> |  |        |  +> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> |  |        |  +> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> |  |        |  +> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> |  |        |  +> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
> |  |        |  +> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
> |  |        |  +> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
> |  |        |  +> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
> |  |        |  +> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
> |  |        |  +> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
> |  |        |  +> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> |  |        |  +> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
> |  |        |  +> TLS_EMPTY_RENEGOTIATION_INFO_SCSV
> |  |        +> Disabled size=18
> ...
>
>
>
> I'm using:
> Jetty version 9.4.21.v20190926
> Java: AdoptOpenJDK OpenJDK 64-Bit Server VM 11.0.4
> OS: Linux amd64 4.15.0-65-generic
>
> Why aren't they offered with tls 1.2?  Can I fix this with configuration?

The only way to know for sure is to grab a network trace between client and 
server and verify who is not offering the ciphers and why.
If you use Java, setting -Djavax.net.debug=all helps understanding what's going 
on at the OpenJDK TLS implementation level (both on client and on server).

I'm inclined to think that the browser does not offer those ciphers, despite 
what the link you reported says.

--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support from the Jetty & CometD 
experts.
_______________________________________________
jetty-users mailing list
[email protected]<mailto:[email protected]>
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
[email protected]<mailto:[email protected]>
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users


--
Glen K. Peterson
(828) 393-0081
_______________________________________________
jetty-users mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

Reply via email to