Supporting strong ciphers in IE11/Win7 (and 8.1)

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Supporting strong ciphers in IE11/Win7 (and 8.1)

Glen Peterson
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&platform=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: 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?

--
Glen K. Peterson
(828) 393-0081

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Supporting strong ciphers in IE11/Win7 (and 8.1)

Simone Bordet-3
Hi,

On Wed, Oct 16, 2019 at 12:03 AM Glen Peterson
<[hidden email]> 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&platform=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: 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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Supporting strong ciphers in IE11/Win7 (and 8.1)

Young, Gregory
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: [hidden email] <[hidden email]> On Behalf Of Simone Bordet
Sent: October 16, 2019 4:24 AM
To: JETTY user mailing list <[hidden email]>
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 <[hidden email]> 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: 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
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Supporting strong ciphers in IE11/Win7 (and 8.1)

Glen Peterson
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 <[hidden email]> 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: [hidden email] <[hidden email]> On Behalf Of Simone Bordet
Sent: October 16, 2019 4:24 AM
To: JETTY user mailing list <[hidden email]>
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 <[hidden email]> 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: 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
[hidden email]
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
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Supporting strong ciphers in IE11/Win7 (and 8.1)

Young, Gregory

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: [hidden email] <[hidden email]> On Behalf Of Glen Peterson
Sent: October 18, 2019 10:30 AM
To: JETTY user mailing list <[hidden email]>
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 <[hidden email]> 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: [hidden email] <[hidden email]> On Behalf Of Simone Bordet
Sent: October 16, 2019 4:24 AM
To: JETTY user mailing list <[hidden email]>
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 <[hidden email]> 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: 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
[hidden email]
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
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Supporting strong ciphers in IE11/Win7 (and 8.1)

Glen Peterson
Ok Simone, I did 4 tests:

1. Wireshark

I dumped the connection and protocol negotiation with wireshark as I issued an nmap ssl-enum-ciphers.  I don't know what I'm looking at, so I'm just attaching the dump file so that smarter minds than mine can figure it out.

2. -Djavax.net.debug=all
Running with:
$ java -Djavax.net.debug=all -jar target/ROOT.jar

Testing with:
$ nmap --script ssl-enum-ciphers -p 8443 localhost

I get one line of output in the application logs:
javax.net.ssl|DEBUG|0C|qtp518522822-12|2019-10-18 14:14:40.086 EDT|SunX509KeyManagerImpl.java:392|matching alias: jetty

3. openssl s_client

$ echo | openssl s_client -connect localhost:8443
CONNECTED(00000005)
depth=0 C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
verify return:1
---
Certificate chain
 0 s:C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
   i:C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDszCCApugAwIBAgIEdU7eqTANBgkqhkiG9w0BAQsFADCBiTELMAkGA1UEBhMC
VVMxFzAVBgNVBAgTDlNvdXRoIENhcm9saW5hMRAwDgYDVQQHEwdVcHN0YXRlMRYw
FAYDVQQKEw1PcmdhbmljRGVzaWduMRAwDgYDVQQLEwdUZXN0aW5nMSUwIwYDVQQD
ExxjbGFzc1ZzSmFyLm9yZ2FuaWNkZXNpZ24ub3JnMB4XDTE5MTAwMjIwNTMzNVoX
DTIyMTAwMjIwNTMzNVowgYkxCzAJBgNVBAYTAlVTMRcwFQYDVQQIEw5Tb3V0aCBD
YXJvbGluYTEQMA4GA1UEBxMHVXBzdGF0ZTEWMBQGA1UEChMNT3JnYW5pY0Rlc2ln
bjEQMA4GA1UECxMHVGVzdGluZzElMCMGA1UEAxMcY2xhc3NWc0phci5vcmdhbmlj
ZGVzaWduLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ56Z+Fv
W1iQsW19is/NCEVg7zoMJBzROosz/JhMXQfb2GDAc90mr9LcrNUVItHxBa1X14h+
6Pen8IOMon5zDUUCZ1HNqPbEIuUV4asTiWKKtGdLVU6dyljXHiXwnfhSFT8IALs8
AN9xYcJED0KJk21HRR5ZHJ/Focg0xTfuwgzMRDR1GUsYYDrveNKWyXK0/auH8pBv
Y4c1Mq7mK1UNZmWtj+lJs6jZm/WvZ6id8ZKhSvRHeFsYQWZ8RI7VkQn1uXQLOXW7
kOTbISNBYi775w2ryxzTRL7Iypo5E0cjVhBANOa7+S8TbBhLpZvW1vQbqe7Q6se9
QDgSmZ3pclrIlhMCAwEAAaMhMB8wHQYDVR0OBBYEFJJ4OYMqxaXoo3SdHa2zviae
/leOMA0GCSqGSIb3DQEBCwUAA4IBAQBLBo3H0M+4r6dVn6Kc2rDmugYOJyh2INtY
NlzmF6KrpFpF/ojx9Eb7n0tgU03W5Wxy5E3DTIrbaZGiinTeQDRcPmrN1xXpdyfq
kXxX9DtYOknEaimEytZEZuv934v7qeY+vaFoamixA+xcY1tyGdNSMJTkKCSS/8+u
OlVrIDjbTDVKJQ4iidKTyCZHi3jVvMboMPfQuyaN0xVHIdNz3yXQTOgoaBRpwOrr
vHS93GehMAx+GHez8BSINgxYyDIkL/PAfYH9ReSEp5wwTDczBcPvfbWePhB93dGS
xJEHtFH1MoWYH4fyk1VS8+Bcg7S6pYu1uBJrZzmEVLIbDZ1HrjJz
-----END CERTIFICATE-----
subject=C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org

issuer=C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1441 bytes and written 391 bytes
Verification error: self signed certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self signed certificate)
---
DONE


4. testssh.sh
This looks remarkably similar to the report running ssllabs.

$ ./testssl.sh localhost:8443

###########################################################
    testssl.sh       3.0rc5 from https://testssl.sh/dev/
    (f118085 2019-10-17 09:39:54 -- )

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.2-chacha (1.0.2k-dev)" [~183 ciphers]
 on glensDesktop:./bin/openssl.Linux.x86_64
 (built: "Jan 18 17:12:17 2019", platform: "linux-x86_64")


 Start 2019-10-18 14:23:25        -->> 127.0.0.1:8443 (localhost) <<--

 A record via:           /etc/hosts
 rDNS (127.0.0.1):       db.dev.memoryjoggerlibrary.com.dev.planbase.com.nethackwiki.com.nethack.wikia.com.www.steelypips.org.nethack.org.alt.org.ninjakiwi.com.gamesgames.com.playdos.games.classicreload.com.archive.org.playretrogames.com.ssega.com.myabandonware.com.www.cosumi.net.online-go.com.
 Service detected:       Couldn't determine what's running on port 8443, assuming no HTTP service => skipping all HTTP checks


 Testing protocols via sockets except NPN+ALPN

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      not offered
 TLS 1.1    not offered
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final
 NPN/SPDY   not offered
 ALPN/HTTP2 h2, spdy/3.1, http/1.1, grpc-exp, h2-fb, spdy/1, spdy/2, spdy/3, stun.turn, stun.nat-discovery, webrtc, c-webrtc, ftp (offered)

 Testing cipher categories

 NULL ciphers (no encryption)                  not offered (OK)
 Anonymous NULL Ciphers (no authentication)    not offered (OK)
 Export ciphers (w/o ADH+NULL)                 not offered (OK)
 LOW: 64 Bit + DES, RC[2,4] (w/o export)       not offered (OK)
 Triple DES Ciphers / IDEA                     not offered (OK)
 Average: SEED + 128+256 Bit CBC ciphers       not offered
 Strong encryption (AEAD ciphers)              offered (OK)


 Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4

 PFS is offered (OK)          TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 ECDHE-RSA-AES256-GCM-SHA384
                              ECDHE-RSA-CHACHA20-POLY1305 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256
 Elliptic curves offered:     prime256v1 secp384r1 X25519


 Testing server preferences

 Has server cipher order?     yes (OK) -- only for < TLS 1.3
 Negotiated protocol          TLSv1.3
 Negotiated cipher            TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
 Cipher order
    TLSv1.2:   ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305
    TLSv1.3:   TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256


 Testing server defaults (Server Hello)

 TLS extensions (standard)    "renegotiation info/#65281" "EC point formats/#11" "key share/#51"
                              "supported versions/#43" "extended master secret/#23"
                              "application layer protocol negotiation/#16"
 Session Ticket RFC 5077 hint no -- no lifetime advertised
 SSL Session ID support       yes
 Session Resumption           Tickets no, ID: yes
 TLS clock skew               0 sec from localtime
 Signature Algorithm          SHA256 with RSA
 Server key size              RSA 2048 bits
 Server key usage             --
 Server extended key usage    --
 Serial / Fingerprints        754EDEA9 / SHA1 0B626941D68F533389ABD32D3A632D8F1E5590BD
                              SHA256 9C8C0FB52E92781BD8CFD50651E8664CF77BDD72A73031E228C2A539E0F4A4A3
 Common Name (CN)             classVsJar.organicdesign.org
 subjectAltName (SAN)         missing -- no SAN is deprecated
 Issuer                       self-signed (NOT ok)
 Trust (hostname)             certificate does not match supplied URI (same w/o SNI)
 Chain of trust               NOT ok (self signed)
 EV cert (experimental)       no
 ETS/"eTLS", visibility info  not present
 Certificate Validity (UTC)   1080 >= 60 days (2019-10-02 16:53 --> 2022-10-02 16:53)
 # of certificates provided   1
 Certificate Revocation List  --
 OCSP URI                     --
                              NOT ok -- neither CRL nor OCSP URI provided
 OCSP stapling                not offered
 OCSP must staple extension   --
 DNS CAA RR (experimental)    not offered
 Certificate Transparency     N/A


 Testing vulnerabilities

 Heartbleed (CVE-2014-0160)                not vulnerable (OK), no heartbeat extension
 CCS (CVE-2014-0224)                       not vulnerable (OK)
 Ticketbleed (CVE-2016-9244), experiment.  --   (applicable only for HTTPS)
 ROBOT                                     Server does not support any cipher suites that use RSA key transport
 Secure Renegotiation (RFC 5746)           supported (OK)
 Secure Client-Initiated Renegotiation     likely not vulnerable (OK), timed out
 CRIME, TLS (CVE-2012-4929)                not vulnerable (OK) (not using HTTP anyway)
 POODLE, SSL (CVE-2014-3566)               not vulnerable (OK)
 TLS_FALLBACK_SCSV (RFC 7507)              No fallback possible, no protocol below TLS 1.2 offered (OK)
 SWEET32 (CVE-2016-2183, CVE-2016-6329)    not vulnerable (OK)
 FREAK (CVE-2015-0204)                     not vulnerable (OK)
 DROWN (CVE-2016-0800, CVE-2016-0703)      not vulnerable on this host and port (OK)
                                           make sure you don't use this certificate elsewhere with SSLv2 enabled services
                                           https://censys.io/ipv4?q=9C8C0FB52E92781BD8CFD50651E8664CF77BDD72A73031E228C2A539E0F4A4A3 could help you to find out
 LOGJAM (CVE-2015-4000), experimental      not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
 BEAST (CVE-2011-3389)                     no SSL3 or TLS1 (OK)
 LUCKY13 (CVE-2013-0169), experimental     not vulnerable (OK)
 RC4 (CVE-2013-2566, CVE-2015-2808)        no RC4 ciphers detected (OK)


 Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.   Encryption  Bits     Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384                            
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256                      
 xc030   ECDHE-RSA-AES256-GCM-SHA384       ECDH 256   AESGCM      256      TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384              
 xcca8   ECDHE-RSA-CHACHA20-POLY1305       ECDH 253   ChaCha20    256      TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256        
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256                            
 xc02f   ECDHE-RSA-AES128-GCM-SHA256       ECDH 256   AESGCM      128      TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256              

Could not determine the protocol, only simulating generic clients.

 Running client simulations via sockets

 Android 4.4.2                TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 5.0.0                TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 6.0                  TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 7.0                  TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Android 8.1 (native)         TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Android 9.0 (native)         TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Chrome 65 Win 7              TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Chrome 74 (Win 10)           TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Firefox 62 Win 7             TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Firefox 66 (Win 8.1/10)      TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 IE 6 XP                      No connection
 IE 8 Win 7                   No connection
 IE 8 XP                      No connection
 IE 11 Win 7                  No connection
 IE 11 Win 8.1                No connection
 IE 11 Win Phone 8.1          No connection
 IE 11 Win 10                 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Edge 15 Win 10               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Edge 17 (Win 10)             TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Opera 60 (Win 10)            TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Safari 9 iOS 9               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 9 OS X 10.11          TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 10 OS X 10.12         TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 12.1 (iOS 12.2)       TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 253 bit ECDH (X25519)
 Safari 13.0 (macOS 10.14.6)  TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 253 bit ECDH (X25519)
 Apple ATS 9 iOS 9            TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Java 6u45                    No connection
 Java 7u25                    No connection
 Java 8u161                   TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Java 11.0.2 (OpenJDK)        TLSv1.3 TLS_AES_128_GCM_SHA256, 256 bit ECDH (P-256)
 Java 12.0.1 (OpenJDK)        TLSv1.3 TLS_AES_128_GCM_SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.0.1l               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.0.2e               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.1.0j (Debian)      TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 OpenSSL 1.1.1b (Debian)      TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
 Thunderbird (60.6)           TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)

 Done 2019-10-18 14:24:11 [  47s] -->> 127.0.0.1:8443 (localhost) <<--


On Fri, Oct 18, 2019 at 11:27 AM Young, Gregory <[hidden email]> wrote:

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: [hidden email] <[hidden email]> On Behalf Of Glen Peterson
Sent: October 18, 2019 10:30 AM
To: JETTY user mailing list <[hidden email]>
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 <[hidden email]> 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: [hidden email] <[hidden email]> On Behalf Of Simone Bordet
Sent: October 16, 2019 4:24 AM
To: JETTY user mailing list <[hidden email]>
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 <[hidden email]> 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: 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users

wiresharkScan.pcapng (174K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Supporting strong ciphers in IE11/Win7 (and 8.1)

Glen Peterson
P.S. I posted a minimal sample project on Git (you may recognize it from my last question).

On Fri, Oct 18, 2019 at 3:46 PM Glen Peterson <[hidden email]> wrote:
Ok Simone, I did 4 tests:

1. Wireshark

I dumped the connection and protocol negotiation with wireshark as I issued an nmap ssl-enum-ciphers.  I don't know what I'm looking at, so I'm just attaching the dump file so that smarter minds than mine can figure it out.

2. -Djavax.net.debug=all
Running with:
$ java -Djavax.net.debug=all -jar target/ROOT.jar

Testing with:
$ nmap --script ssl-enum-ciphers -p 8443 localhost

I get one line of output in the application logs:
javax.net.ssl|DEBUG|0C|qtp518522822-12|2019-10-18 14:14:40.086 EDT|SunX509KeyManagerImpl.java:392|matching alias: jetty

3. openssl s_client

$ echo | openssl s_client -connect localhost:8443
CONNECTED(00000005)
depth=0 C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
verify return:1
---
Certificate chain
 0 s:C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
   i:C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDszCCApugAwIBAgIEdU7eqTANBgkqhkiG9w0BAQsFADCBiTELMAkGA1UEBhMC
VVMxFzAVBgNVBAgTDlNvdXRoIENhcm9saW5hMRAwDgYDVQQHEwdVcHN0YXRlMRYw
FAYDVQQKEw1PcmdhbmljRGVzaWduMRAwDgYDVQQLEwdUZXN0aW5nMSUwIwYDVQQD
ExxjbGFzc1ZzSmFyLm9yZ2FuaWNkZXNpZ24ub3JnMB4XDTE5MTAwMjIwNTMzNVoX
DTIyMTAwMjIwNTMzNVowgYkxCzAJBgNVBAYTAlVTMRcwFQYDVQQIEw5Tb3V0aCBD
YXJvbGluYTEQMA4GA1UEBxMHVXBzdGF0ZTEWMBQGA1UEChMNT3JnYW5pY0Rlc2ln
bjEQMA4GA1UECxMHVGVzdGluZzElMCMGA1UEAxMcY2xhc3NWc0phci5vcmdhbmlj
ZGVzaWduLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ56Z+Fv
W1iQsW19is/NCEVg7zoMJBzROosz/JhMXQfb2GDAc90mr9LcrNUVItHxBa1X14h+
6Pen8IOMon5zDUUCZ1HNqPbEIuUV4asTiWKKtGdLVU6dyljXHiXwnfhSFT8IALs8
AN9xYcJED0KJk21HRR5ZHJ/Focg0xTfuwgzMRDR1GUsYYDrveNKWyXK0/auH8pBv
Y4c1Mq7mK1UNZmWtj+lJs6jZm/WvZ6id8ZKhSvRHeFsYQWZ8RI7VkQn1uXQLOXW7
kOTbISNBYi775w2ryxzTRL7Iypo5E0cjVhBANOa7+S8TbBhLpZvW1vQbqe7Q6se9
QDgSmZ3pclrIlhMCAwEAAaMhMB8wHQYDVR0OBBYEFJJ4OYMqxaXoo3SdHa2zviae
/leOMA0GCSqGSIb3DQEBCwUAA4IBAQBLBo3H0M+4r6dVn6Kc2rDmugYOJyh2INtY
NlzmF6KrpFpF/ojx9Eb7n0tgU03W5Wxy5E3DTIrbaZGiinTeQDRcPmrN1xXpdyfq
kXxX9DtYOknEaimEytZEZuv934v7qeY+vaFoamixA+xcY1tyGdNSMJTkKCSS/8+u
OlVrIDjbTDVKJQ4iidKTyCZHi3jVvMboMPfQuyaN0xVHIdNz3yXQTOgoaBRpwOrr
vHS93GehMAx+GHez8BSINgxYyDIkL/PAfYH9ReSEp5wwTDczBcPvfbWePhB93dGS
xJEHtFH1MoWYH4fyk1VS8+Bcg7S6pYu1uBJrZzmEVLIbDZ1HrjJz
-----END CERTIFICATE-----
subject=C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org

issuer=C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1441 bytes and written 391 bytes
Verification error: self signed certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self signed certificate)
---
DONE


4. testssh.sh
This looks remarkably similar to the report running ssllabs.

$ ./testssl.sh localhost:8443

###########################################################
    testssl.sh       3.0rc5 from https://testssl.sh/dev/
    (f118085 2019-10-17 09:39:54 -- )

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.2-chacha (1.0.2k-dev)" [~183 ciphers]
 on glensDesktop:./bin/openssl.Linux.x86_64
 (built: "Jan 18 17:12:17 2019", platform: "linux-x86_64")


 Start 2019-10-18 14:23:25        -->> 127.0.0.1:8443 (localhost) <<--

 A record via:           /etc/hosts
 rDNS (127.0.0.1):       db.dev.memoryjoggerlibrary.com.dev.planbase.com.nethackwiki.com.nethack.wikia.com.www.steelypips.org.nethack.org.alt.org.ninjakiwi.com.gamesgames.com.playdos.games.classicreload.com.archive.org.playretrogames.com.ssega.com.myabandonware.com.www.cosumi.net.online-go.com.
 Service detected:       Couldn't determine what's running on port 8443, assuming no HTTP service => skipping all HTTP checks


 Testing protocols via sockets except NPN+ALPN

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      not offered
 TLS 1.1    not offered
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final
 NPN/SPDY   not offered
 ALPN/HTTP2 h2, spdy/3.1, http/1.1, grpc-exp, h2-fb, spdy/1, spdy/2, spdy/3, stun.turn, stun.nat-discovery, webrtc, c-webrtc, ftp (offered)

 Testing cipher categories

 NULL ciphers (no encryption)                  not offered (OK)
 Anonymous NULL Ciphers (no authentication)    not offered (OK)
 Export ciphers (w/o ADH+NULL)                 not offered (OK)
 LOW: 64 Bit + DES, RC[2,4] (w/o export)       not offered (OK)
 Triple DES Ciphers / IDEA                     not offered (OK)
 Average: SEED + 128+256 Bit CBC ciphers       not offered
 Strong encryption (AEAD ciphers)              offered (OK)


 Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4

 PFS is offered (OK)          TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 ECDHE-RSA-AES256-GCM-SHA384
                              ECDHE-RSA-CHACHA20-POLY1305 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256
 Elliptic curves offered:     prime256v1 secp384r1 X25519


 Testing server preferences

 Has server cipher order?     yes (OK) -- only for < TLS 1.3
 Negotiated protocol          TLSv1.3
 Negotiated cipher            TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
 Cipher order
    TLSv1.2:   ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305
    TLSv1.3:   TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256


 Testing server defaults (Server Hello)

 TLS extensions (standard)    "renegotiation info/#65281" "EC point formats/#11" "key share/#51"
                              "supported versions/#43" "extended master secret/#23"
                              "application layer protocol negotiation/#16"
 Session Ticket RFC 5077 hint no -- no lifetime advertised
 SSL Session ID support       yes
 Session Resumption           Tickets no, ID: yes
 TLS clock skew               0 sec from localtime
 Signature Algorithm          SHA256 with RSA
 Server key size              RSA 2048 bits
 Server key usage             --
 Server extended key usage    --
 Serial / Fingerprints        754EDEA9 / SHA1 0B626941D68F533389ABD32D3A632D8F1E5590BD
                              SHA256 9C8C0FB52E92781BD8CFD50651E8664CF77BDD72A73031E228C2A539E0F4A4A3
 Common Name (CN)             classVsJar.organicdesign.org
 subjectAltName (SAN)         missing -- no SAN is deprecated
 Issuer                       self-signed (NOT ok)
 Trust (hostname)             certificate does not match supplied URI (same w/o SNI)
 Chain of trust               NOT ok (self signed)
 EV cert (experimental)       no
 ETS/"eTLS", visibility info  not present
 Certificate Validity (UTC)   1080 >= 60 days (2019-10-02 16:53 --> 2022-10-02 16:53)
 # of certificates provided   1
 Certificate Revocation List  --
 OCSP URI                     --
                              NOT ok -- neither CRL nor OCSP URI provided
 OCSP stapling                not offered
 OCSP must staple extension   --
 DNS CAA RR (experimental)    not offered
 Certificate Transparency     N/A


 Testing vulnerabilities

 Heartbleed (CVE-2014-0160)                not vulnerable (OK), no heartbeat extension
 CCS (CVE-2014-0224)                       not vulnerable (OK)
 Ticketbleed (CVE-2016-9244), experiment.  --   (applicable only for HTTPS)
 ROBOT                                     Server does not support any cipher suites that use RSA key transport
 Secure Renegotiation (RFC 5746)           supported (OK)
 Secure Client-Initiated Renegotiation     likely not vulnerable (OK), timed out
 CRIME, TLS (CVE-2012-4929)                not vulnerable (OK) (not using HTTP anyway)
 POODLE, SSL (CVE-2014-3566)               not vulnerable (OK)
 TLS_FALLBACK_SCSV (RFC 7507)              No fallback possible, no protocol below TLS 1.2 offered (OK)
 SWEET32 (CVE-2016-2183, CVE-2016-6329)    not vulnerable (OK)
 FREAK (CVE-2015-0204)                     not vulnerable (OK)
 DROWN (CVE-2016-0800, CVE-2016-0703)      not vulnerable on this host and port (OK)
                                           make sure you don't use this certificate elsewhere with SSLv2 enabled services
                                           https://censys.io/ipv4?q=9C8C0FB52E92781BD8CFD50651E8664CF77BDD72A73031E228C2A539E0F4A4A3 could help you to find out
 LOGJAM (CVE-2015-4000), experimental      not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
 BEAST (CVE-2011-3389)                     no SSL3 or TLS1 (OK)
 LUCKY13 (CVE-2013-0169), experimental     not vulnerable (OK)
 RC4 (CVE-2013-2566, CVE-2015-2808)        no RC4 ciphers detected (OK)


 Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.   Encryption  Bits     Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384                            
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256                      
 xc030   ECDHE-RSA-AES256-GCM-SHA384       ECDH 256   AESGCM      256      TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384              
 xcca8   ECDHE-RSA-CHACHA20-POLY1305       ECDH 253   ChaCha20    256      TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256        
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256                            
 xc02f   ECDHE-RSA-AES128-GCM-SHA256       ECDH 256   AESGCM      128      TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256              

Could not determine the protocol, only simulating generic clients.

 Running client simulations via sockets

 Android 4.4.2                TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 5.0.0                TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 6.0                  TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 7.0                  TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Android 8.1 (native)         TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Android 9.0 (native)         TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Chrome 65 Win 7              TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Chrome 74 (Win 10)           TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Firefox 62 Win 7             TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Firefox 66 (Win 8.1/10)      TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 IE 6 XP                      No connection
 IE 8 Win 7                   No connection
 IE 8 XP                      No connection
 IE 11 Win 7                  No connection
 IE 11 Win 8.1                No connection
 IE 11 Win Phone 8.1          No connection
 IE 11 Win 10                 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Edge 15 Win 10               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Edge 17 (Win 10)             TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Opera 60 (Win 10)            TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Safari 9 iOS 9               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 9 OS X 10.11          TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 10 OS X 10.12         TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 12.1 (iOS 12.2)       TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 253 bit ECDH (X25519)
 Safari 13.0 (macOS 10.14.6)  TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 253 bit ECDH (X25519)
 Apple ATS 9 iOS 9            TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Java 6u45                    No connection
 Java 7u25                    No connection
 Java 8u161                   TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Java 11.0.2 (OpenJDK)        TLSv1.3 TLS_AES_128_GCM_SHA256, 256 bit ECDH (P-256)
 Java 12.0.1 (OpenJDK)        TLSv1.3 TLS_AES_128_GCM_SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.0.1l               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.0.2e               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.1.0j (Debian)      TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 OpenSSL 1.1.1b (Debian)      TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
 Thunderbird (60.6)           TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)

 Done 2019-10-18 14:24:11 [  47s] -->> 127.0.0.1:8443 (localhost) <<--


On Fri, Oct 18, 2019 at 11:27 AM Young, Gregory <[hidden email]> wrote:

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: [hidden email] <[hidden email]> On Behalf Of Glen Peterson
Sent: October 18, 2019 10:30 AM
To: JETTY user mailing list <[hidden email]>
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 <[hidden email]> 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: [hidden email] <[hidden email]> On Behalf Of Simone Bordet
Sent: October 16, 2019 4:24 AM
To: JETTY user mailing list <[hidden email]>
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 <[hidden email]> 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: 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
[hidden email]
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
[hidden email]
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
[hidden email]
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


--
Glen K. Peterson
(828) 393-0081

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Supporting strong ciphers in IE11/Win7 (and 8.1)

Glen Peterson
I figured it out.

1. Use an EC certificate:
sudo $JAVA_HOME/bin/keytool \
   -alias jetty \
   -dname "CN=classVsJar.organicdesign.org, OU=Testing, O=OrganicDesign, L=Upstate, ST=South Carolina, C=US" \
   -genkeypair \
   -keyalg EC \
   -keysize 256 \
   -keystore src/main/resources/keystore \
   -sigalg SHA256withECDSA \
   -storetype pkcs12 \
   -validity 1096

Source 1:
Gregory Young: "2. for the TLS_ECDHE_ECDSA_* ciphers to be available, you need to add a newer ECDSA signed SSL certificate to the keystore."  I was unable to add a second certificate to the keystore, but I was able to make a new keystore with an EC cert:

Source 2:
testssl.sh shows the DHE ciphers supported by IE as weak, even though SSLLabs shows them green (strong).  I'm thinking weak is probably appropriate because of this: https://weakdh.org/

2. IE11/Win8.1 needs to see http1.1 first - before h2.
So I removed this line:
// alpn.defaultProtocol = "h2"

Source 1:
Simone Bordet's comment on this issue:

Source 2:
As several people have alluded to, IE11 does not support http/2 on Windows 7 or 8.1: "Partial support [for Http2] in Internet Explorer refers to being limited to Windows 10."

Epilogue:
I'm probably going to have to support IE11/Win8.1 until January 2023:
"Windows 8.1 falls under the same lifecycle policy as Windows 8, and will reach end of Mainstream Support on January 9, 2018, and end of Extended Support on January 10, 2023."
Source:

On Fri, Oct 18, 2019 at 5:27 PM Glen Peterson <[hidden email]> wrote:
P.S. I posted a minimal sample project on Git (you may recognize it from my last question).

On Fri, Oct 18, 2019 at 3:46 PM Glen Peterson <[hidden email]> wrote:
Ok Simone, I did 4 tests:

1. Wireshark

I dumped the connection and protocol negotiation with wireshark as I issued an nmap ssl-enum-ciphers.  I don't know what I'm looking at, so I'm just attaching the dump file so that smarter minds than mine can figure it out.

2. -Djavax.net.debug=all
Running with:
$ java -Djavax.net.debug=all -jar target/ROOT.jar

Testing with:
$ nmap --script ssl-enum-ciphers -p 8443 localhost

I get one line of output in the application logs:
javax.net.ssl|DEBUG|0C|qtp518522822-12|2019-10-18 14:14:40.086 EDT|SunX509KeyManagerImpl.java:392|matching alias: jetty

3. openssl s_client

$ echo | openssl s_client -connect localhost:8443
CONNECTED(00000005)
depth=0 C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
verify return:1
---
Certificate chain
 0 s:C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
   i:C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDszCCApugAwIBAgIEdU7eqTANBgkqhkiG9w0BAQsFADCBiTELMAkGA1UEBhMC
VVMxFzAVBgNVBAgTDlNvdXRoIENhcm9saW5hMRAwDgYDVQQHEwdVcHN0YXRlMRYw
FAYDVQQKEw1PcmdhbmljRGVzaWduMRAwDgYDVQQLEwdUZXN0aW5nMSUwIwYDVQQD
ExxjbGFzc1ZzSmFyLm9yZ2FuaWNkZXNpZ24ub3JnMB4XDTE5MTAwMjIwNTMzNVoX
DTIyMTAwMjIwNTMzNVowgYkxCzAJBgNVBAYTAlVTMRcwFQYDVQQIEw5Tb3V0aCBD
YXJvbGluYTEQMA4GA1UEBxMHVXBzdGF0ZTEWMBQGA1UEChMNT3JnYW5pY0Rlc2ln
bjEQMA4GA1UECxMHVGVzdGluZzElMCMGA1UEAxMcY2xhc3NWc0phci5vcmdhbmlj
ZGVzaWduLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ56Z+Fv
W1iQsW19is/NCEVg7zoMJBzROosz/JhMXQfb2GDAc90mr9LcrNUVItHxBa1X14h+
6Pen8IOMon5zDUUCZ1HNqPbEIuUV4asTiWKKtGdLVU6dyljXHiXwnfhSFT8IALs8
AN9xYcJED0KJk21HRR5ZHJ/Focg0xTfuwgzMRDR1GUsYYDrveNKWyXK0/auH8pBv
Y4c1Mq7mK1UNZmWtj+lJs6jZm/WvZ6id8ZKhSvRHeFsYQWZ8RI7VkQn1uXQLOXW7
kOTbISNBYi775w2ryxzTRL7Iypo5E0cjVhBANOa7+S8TbBhLpZvW1vQbqe7Q6se9
QDgSmZ3pclrIlhMCAwEAAaMhMB8wHQYDVR0OBBYEFJJ4OYMqxaXoo3SdHa2zviae
/leOMA0GCSqGSIb3DQEBCwUAA4IBAQBLBo3H0M+4r6dVn6Kc2rDmugYOJyh2INtY
NlzmF6KrpFpF/ojx9Eb7n0tgU03W5Wxy5E3DTIrbaZGiinTeQDRcPmrN1xXpdyfq
kXxX9DtYOknEaimEytZEZuv934v7qeY+vaFoamixA+xcY1tyGdNSMJTkKCSS/8+u
OlVrIDjbTDVKJQ4iidKTyCZHi3jVvMboMPfQuyaN0xVHIdNz3yXQTOgoaBRpwOrr
vHS93GehMAx+GHez8BSINgxYyDIkL/PAfYH9ReSEp5wwTDczBcPvfbWePhB93dGS
xJEHtFH1MoWYH4fyk1VS8+Bcg7S6pYu1uBJrZzmEVLIbDZ1HrjJz
-----END CERTIFICATE-----
subject=C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org

issuer=C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1441 bytes and written 391 bytes
Verification error: self signed certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self signed certificate)
---
DONE


4. testssh.sh
This looks remarkably similar to the report running ssllabs.

$ ./testssl.sh localhost:8443

###########################################################
    testssl.sh       3.0rc5 from https://testssl.sh/dev/
    (f118085 2019-10-17 09:39:54 -- )

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.2-chacha (1.0.2k-dev)" [~183 ciphers]
 on glensDesktop:./bin/openssl.Linux.x86_64
 (built: "Jan 18 17:12:17 2019", platform: "linux-x86_64")


 Start 2019-10-18 14:23:25        -->> 127.0.0.1:8443 (localhost) <<--

 A record via:           /etc/hosts
 rDNS (127.0.0.1):       db.dev.memoryjoggerlibrary.com.dev.planbase.com.nethackwiki.com.nethack.wikia.com.www.steelypips.org.nethack.org.alt.org.ninjakiwi.com.gamesgames.com.playdos.games.classicreload.com.archive.org.playretrogames.com.ssega.com.myabandonware.com.www.cosumi.net.online-go.com.
 Service detected:       Couldn't determine what's running on port 8443, assuming no HTTP service => skipping all HTTP checks


 Testing protocols via sockets except NPN+ALPN

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      not offered
 TLS 1.1    not offered
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final
 NPN/SPDY   not offered
 ALPN/HTTP2 h2, spdy/3.1, http/1.1, grpc-exp, h2-fb, spdy/1, spdy/2, spdy/3, stun.turn, stun.nat-discovery, webrtc, c-webrtc, ftp (offered)

 Testing cipher categories

 NULL ciphers (no encryption)                  not offered (OK)
 Anonymous NULL Ciphers (no authentication)    not offered (OK)
 Export ciphers (w/o ADH+NULL)                 not offered (OK)
 LOW: 64 Bit + DES, RC[2,4] (w/o export)       not offered (OK)
 Triple DES Ciphers / IDEA                     not offered (OK)
 Average: SEED + 128+256 Bit CBC ciphers       not offered
 Strong encryption (AEAD ciphers)              offered (OK)


 Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4

 PFS is offered (OK)          TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 ECDHE-RSA-AES256-GCM-SHA384
                              ECDHE-RSA-CHACHA20-POLY1305 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256
 Elliptic curves offered:     prime256v1 secp384r1 X25519


 Testing server preferences

 Has server cipher order?     yes (OK) -- only for < TLS 1.3
 Negotiated protocol          TLSv1.3
 Negotiated cipher            TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
 Cipher order
    TLSv1.2:   ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305
    TLSv1.3:   TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256


 Testing server defaults (Server Hello)

 TLS extensions (standard)    "renegotiation info/#65281" "EC point formats/#11" "key share/#51"
                              "supported versions/#43" "extended master secret/#23"
                              "application layer protocol negotiation/#16"
 Session Ticket RFC 5077 hint no -- no lifetime advertised
 SSL Session ID support       yes
 Session Resumption           Tickets no, ID: yes
 TLS clock skew               0 sec from localtime
 Signature Algorithm          SHA256 with RSA
 Server key size              RSA 2048 bits
 Server key usage             --
 Server extended key usage    --
 Serial / Fingerprints        754EDEA9 / SHA1 0B626941D68F533389ABD32D3A632D8F1E5590BD
                              SHA256 9C8C0FB52E92781BD8CFD50651E8664CF77BDD72A73031E228C2A539E0F4A4A3
 Common Name (CN)             classVsJar.organicdesign.org
 subjectAltName (SAN)         missing -- no SAN is deprecated
 Issuer                       self-signed (NOT ok)
 Trust (hostname)             certificate does not match supplied URI (same w/o SNI)
 Chain of trust               NOT ok (self signed)
 EV cert (experimental)       no
 ETS/"eTLS", visibility info  not present
 Certificate Validity (UTC)   1080 >= 60 days (2019-10-02 16:53 --> 2022-10-02 16:53)
 # of certificates provided   1
 Certificate Revocation List  --
 OCSP URI                     --
                              NOT ok -- neither CRL nor OCSP URI provided
 OCSP stapling                not offered
 OCSP must staple extension   --
 DNS CAA RR (experimental)    not offered
 Certificate Transparency     N/A


 Testing vulnerabilities

 Heartbleed (CVE-2014-0160)                not vulnerable (OK), no heartbeat extension
 CCS (CVE-2014-0224)                       not vulnerable (OK)
 Ticketbleed (CVE-2016-9244), experiment.  --   (applicable only for HTTPS)
 ROBOT                                     Server does not support any cipher suites that use RSA key transport
 Secure Renegotiation (RFC 5746)           supported (OK)
 Secure Client-Initiated Renegotiation     likely not vulnerable (OK), timed out
 CRIME, TLS (CVE-2012-4929)                not vulnerable (OK) (not using HTTP anyway)
 POODLE, SSL (CVE-2014-3566)               not vulnerable (OK)
 TLS_FALLBACK_SCSV (RFC 7507)              No fallback possible, no protocol below TLS 1.2 offered (OK)
 SWEET32 (CVE-2016-2183, CVE-2016-6329)    not vulnerable (OK)
 FREAK (CVE-2015-0204)                     not vulnerable (OK)
 DROWN (CVE-2016-0800, CVE-2016-0703)      not vulnerable on this host and port (OK)
                                           make sure you don't use this certificate elsewhere with SSLv2 enabled services
                                           https://censys.io/ipv4?q=9C8C0FB52E92781BD8CFD50651E8664CF77BDD72A73031E228C2A539E0F4A4A3 could help you to find out
 LOGJAM (CVE-2015-4000), experimental      not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
 BEAST (CVE-2011-3389)                     no SSL3 or TLS1 (OK)
 LUCKY13 (CVE-2013-0169), experimental     not vulnerable (OK)
 RC4 (CVE-2013-2566, CVE-2015-2808)        no RC4 ciphers detected (OK)


 Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.   Encryption  Bits     Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384                            
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256                      
 xc030   ECDHE-RSA-AES256-GCM-SHA384       ECDH 256   AESGCM      256      TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384              
 xcca8   ECDHE-RSA-CHACHA20-POLY1305       ECDH 253   ChaCha20    256      TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256        
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256                            
 xc02f   ECDHE-RSA-AES128-GCM-SHA256       ECDH 256   AESGCM      128      TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256              

Could not determine the protocol, only simulating generic clients.

 Running client simulations via sockets

 Android 4.4.2                TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 5.0.0                TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 6.0                  TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 7.0                  TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Android 8.1 (native)         TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Android 9.0 (native)         TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Chrome 65 Win 7              TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Chrome 74 (Win 10)           TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Firefox 62 Win 7             TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Firefox 66 (Win 8.1/10)      TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 IE 6 XP                      No connection
 IE 8 Win 7                   No connection
 IE 8 XP                      No connection
 IE 11 Win 7                  No connection
 IE 11 Win 8.1                No connection
 IE 11 Win Phone 8.1          No connection
 IE 11 Win 10                 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Edge 15 Win 10               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Edge 17 (Win 10)             TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Opera 60 (Win 10)            TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Safari 9 iOS 9               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 9 OS X 10.11          TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 10 OS X 10.12         TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 12.1 (iOS 12.2)       TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 253 bit ECDH (X25519)
 Safari 13.0 (macOS 10.14.6)  TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 253 bit ECDH (X25519)
 Apple ATS 9 iOS 9            TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Java 6u45                    No connection
 Java 7u25                    No connection
 Java 8u161                   TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Java 11.0.2 (OpenJDK)        TLSv1.3 TLS_AES_128_GCM_SHA256, 256 bit ECDH (P-256)
 Java 12.0.1 (OpenJDK)        TLSv1.3 TLS_AES_128_GCM_SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.0.1l               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.0.2e               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.1.0j (Debian)      TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 OpenSSL 1.1.1b (Debian)      TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
 Thunderbird (60.6)           TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)

 Done 2019-10-18 14:24:11 [  47s] -->> 127.0.0.1:8443 (localhost) <<--


On Fri, Oct 18, 2019 at 11:27 AM Young, Gregory <[hidden email]> wrote:

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: [hidden email] <[hidden email]> On Behalf Of Glen Peterson
Sent: October 18, 2019 10:30 AM
To: JETTY user mailing list <[hidden email]>
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 <[hidden email]> 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: [hidden email] <[hidden email]> On Behalf Of Simone Bordet
Sent: October 16, 2019 4:24 AM
To: JETTY user mailing list <[hidden email]>
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 <[hidden email]> 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: 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
[hidden email]
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
[hidden email]
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
[hidden email]
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


--
Glen K. Peterson
(828) 393-0081


--
Glen K. Peterson
(828) 393-0081

_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Supporting strong ciphers in IE11/Win7 (and 8.1)

Young, Gregory

Source 1:

Gregory Young: "2. for the TLS_ECDHE_ECDSA_* ciphers to be available, you need to add a newer ECDSA signed SSL certificate to the keystore."  I was unable to add a second certificate to the keystore, but I was able to make a new keystore with an EC cert:

 

You need to use a different alias for the ECDSA signed cert in order to add it to the keystore alongside the RSA signed cert. This is how I do it in my self signed cert generation script:

 

  • /bin/keytool -importkeystore -srckeystore "${rsaPFX}" -srcstoretype "${srcKeystoreType}" -srcstorepass "${srcKeystorePassword}" -srcalias "${srcRSAAlias}" -keystore "${destKeystore}" -deststoretype "${keystoreType}" -deststorepass "${destKeystorePassword}" -destalias "${destRSAAlias}" -destkeypass "${destKeyPassword}"
  • /bin/keytool -importkeystore -srckeystore "${ecdsaPFX}" -srcstoretype "${srcKeystoreType}" -srcstorepass "${srcKeystorePassword}" -srcalias "${srcECDSAAlias}" -keystore "${destKeystore}" -deststoretype "${keystoreType}" -deststorepass "${destKeystorePassword}" -destalias "${destECDSAAlias}" -destkeypass "${destKeyPassword}"

Where:

  • destRSAAlias = “mycert”
  • destECDSAAlias = “mycert-ec”

 

 

Source 2:

testssl.sh shows the DHE ciphers supported by IE as weak, even though SSLLabs shows them green (strong).  I'm thinking weak is probably appropriate because of this: https://weakdh.org/

 

Make sure the DHE ciphers are at least 2048 bit, otherwise they are susceptible to weakDH. Some scanners throw the baby out with the bath water and declare all DH ciphers as weak, and at this time, this is untrue.

 

2. IE11/Win8.1 needs to see http1.1 first - before h2.

So I removed this line:

// alpn.defaultProtocol = "h2"

 

This is consistent with the alpn.ini config as suggested by the alpn.mod file:

 

# ---------------------------------------

# Module: alpn

# Enables the ALPN (Application Layer Protocol Negotiation) TLS extension.

# ---------------------------------------

--module=alpn

 

## Overrides the order protocols are chosen by the server.

## The default order is that specified by the order of the

## modules declared in start.ini.

jetty.alpn.protocols=h2,http/1.1

 

## Specifies what protocol to use when negotiation fails.

jetty.alpn.defaultProtocol=http/1.1

 

 

Gregory Young

 

From: [hidden email] <[hidden email]> On Behalf Of Glen Peterson
Sent: October 21, 2019 6:05 PM
To: JETTY user mailing list <[hidden email]>
Subject: Re: [jetty-users] Supporting strong ciphers in IE11/Win7 (and 8.1)

 

I figured it out.

 

1. Use an EC certificate:

sudo $JAVA_HOME/bin/keytool \

   -alias jetty \
   -dname "CN=classVsJar.organicdesign.org, OU=Testing, O=OrganicDesign, L=Upstate, ST=South Carolina, C=US" \
   -genkeypair \
   -keyalg EC \
   -keysize 256 \
   -keystore src/main/resources/keystore \
   -sigalg SHA256withECDSA \
   -storetype pkcs12 \
   -validity 1096

 

Source 1:

Gregory Young: "2. for the TLS_ECDHE_ECDSA_* ciphers to be available, you need to add a newer ECDSA signed SSL certificate to the keystore."  I was unable to add a second certificate to the keystore, but I was able to make a new keystore with an EC cert:

 

Source 2:

testssl.sh shows the DHE ciphers supported by IE as weak, even though SSLLabs shows them green (strong).  I'm thinking weak is probably appropriate because of this: https://weakdh.org/

 

2. IE11/Win8.1 needs to see http1.1 first - before h2.

So I removed this line:

// alpn.defaultProtocol = "h2"

 

Source 1:

Simone Bordet's comment on this issue:

 

Source 2:

As several people have alluded to, IE11 does not support http/2 on Windows 7 or 8.1: "Partial support [for Http2] in Internet Explorer refers to being limited to Windows 10."

 

Epilogue:

I'm probably going to have to support IE11/Win8.1 until January 2023:

"Windows 8.1 falls under the same lifecycle policy as Windows 8, and will reach end of Mainstream Support on January 9, 2018, and end of Extended Support on January 10, 2023."
Source:

 

On Fri, Oct 18, 2019 at 5:27 PM Glen Peterson <[hidden email]> wrote:

P.S. I posted a minimal sample project on Git (you may recognize it from my last question).

 

On Fri, Oct 18, 2019 at 3:46 PM Glen Peterson <[hidden email]> wrote:

Ok Simone, I did 4 tests:

 

1. Wireshark

 

I dumped the connection and protocol negotiation with wireshark as I issued an nmap ssl-enum-ciphers.  I don't know what I'm looking at, so I'm just attaching the dump file so that smarter minds than mine can figure it out.

 

2. -Djavax.net.debug=all

Running with:

$ java -Djavax.net.debug=all -jar target/ROOT.jar

 

Testing with:

$ nmap --script ssl-enum-ciphers -p 8443 localhost

 

I get one line of output in the application logs:

javax.net.ssl|DEBUG|0C|qtp518522822-12|2019-10-18 14:14:40.086 EDT|SunX509KeyManagerImpl.java:392|matching alias: jetty

 

3. openssl s_client

 

$ echo | openssl s_client -connect localhost:8443

CONNECTED(00000005)
depth=0 C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
verify return:1
---
Certificate chain
 0 s:C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
   i:C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDszCCApugAwIBAgIEdU7eqTANBgkqhkiG9w0BAQsFADCBiTELMAkGA1UEBhMC
VVMxFzAVBgNVBAgTDlNvdXRoIENhcm9saW5hMRAwDgYDVQQHEwdVcHN0YXRlMRYw
FAYDVQQKEw1PcmdhbmljRGVzaWduMRAwDgYDVQQLEwdUZXN0aW5nMSUwIwYDVQQD
ExxjbGFzc1ZzSmFyLm9yZ2FuaWNkZXNpZ24ub3JnMB4XDTE5MTAwMjIwNTMzNVoX
DTIyMTAwMjIwNTMzNVowgYkxCzAJBgNVBAYTAlVTMRcwFQYDVQQIEw5Tb3V0aCBD
YXJvbGluYTEQMA4GA1UEBxMHVXBzdGF0ZTEWMBQGA1UEChMNT3JnYW5pY0Rlc2ln
bjEQMA4GA1UECxMHVGVzdGluZzElMCMGA1UEAxMcY2xhc3NWc0phci5vcmdhbmlj
ZGVzaWduLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ56Z+Fv
W1iQsW19is/NCEVg7zoMJBzROosz/JhMXQfb2GDAc90mr9LcrNUVItHxBa1X14h+
6Pen8IOMon5zDUUCZ1HNqPbEIuUV4asTiWKKtGdLVU6dyljXHiXwnfhSFT8IALs8
AN9xYcJED0KJk21HRR5ZHJ/Focg0xTfuwgzMRDR1GUsYYDrveNKWyXK0/auH8pBv
Y4c1Mq7mK1UNZmWtj+lJs6jZm/WvZ6id8ZKhSvRHeFsYQWZ8RI7VkQn1uXQLOXW7
kOTbISNBYi775w2ryxzTRL7Iypo5E0cjVhBANOa7+S8TbBhLpZvW1vQbqe7Q6se9
QDgSmZ3pclrIlhMCAwEAAaMhMB8wHQYDVR0OBBYEFJJ4OYMqxaXoo3SdHa2zviae
/leOMA0GCSqGSIb3DQEBCwUAA4IBAQBLBo3H0M+4r6dVn6Kc2rDmugYOJyh2INtY
NlzmF6KrpFpF/ojx9Eb7n0tgU03W5Wxy5E3DTIrbaZGiinTeQDRcPmrN1xXpdyfq
kXxX9DtYOknEaimEytZEZuv934v7qeY+vaFoamixA+xcY1tyGdNSMJTkKCSS/8+u
OlVrIDjbTDVKJQ4iidKTyCZHi3jVvMboMPfQuyaN0xVHIdNz3yXQTOgoaBRpwOrr
vHS93GehMAx+GHez8BSINgxYyDIkL/PAfYH9ReSEp5wwTDczBcPvfbWePhB93dGS
xJEHtFH1MoWYH4fyk1VS8+Bcg7S6pYu1uBJrZzmEVLIbDZ1HrjJz
-----END CERTIFICATE-----
subject=C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org

issuer=C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1441 bytes and written 391 bytes
Verification error: self signed certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self signed certificate)
---
DONE

 

4. testssh.sh

This looks remarkably similar to the report running ssllabs.

 

$ ./testssl.sh localhost:8443

###########################################################
    testssl.sh       3.0rc5 from https://testssl.sh/dev/
    (f118085 2019-10-17 09:39:54 -- )

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.2-chacha (1.0.2k-dev)" [~183 ciphers]
 on glensDesktop:./bin/openssl.Linux.x86_64
 (built: "Jan 18 17:12:17 2019", platform: "linux-x86_64")


 Start 2019-10-18 14:23:25        -->> 127.0.0.1:8443 (localhost) <<--

 A record via:           /etc/hosts
 rDNS (127.0.0.1):       db.dev.memoryjoggerlibrary.com.dev.planbase.com.nethackwiki.com.nethack.wikia.com.www.steelypips.org.nethack.org.alt.org.ninjakiwi.com.gamesgames.com.playdos.games.classicreload.com.archive.org.playretrogames.com.ssega.com.myabandonware.com.www.cosumi.net.online-go.com.
 Service detected:       Couldn't determine what's running on port 8443, assuming no HTTP service => skipping all HTTP checks


 Testing protocols via sockets except NPN+ALPN

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      not offered
 TLS 1.1    not offered
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final
 NPN/SPDY   not offered
 ALPN/HTTP2 h2, spdy/3.1, http/1.1, grpc-exp, h2-fb, spdy/1, spdy/2, spdy/3, stun.turn, stun.nat-discovery, webrtc, c-webrtc, ftp (offered)

 Testing cipher categories

 NULL ciphers (no encryption)                  not offered (OK)
 Anonymous NULL Ciphers (no authentication)    not offered (OK)
 Export ciphers (w/o ADH+NULL)                 not offered (OK)
 LOW: 64 Bit + DES, RC[2,4] (w/o export)       not offered (OK)
 Triple DES Ciphers / IDEA                     not offered (OK)
 Average: SEED + 128+256 Bit CBC ciphers       not offered
 Strong encryption (AEAD ciphers)              offered (OK)


 Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4

 PFS is offered (OK)          TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 ECDHE-RSA-AES256-GCM-SHA384
                              ECDHE-RSA-CHACHA20-POLY1305 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256
 Elliptic curves offered:     prime256v1 secp384r1 X25519


 Testing server preferences

 Has server cipher order?     yes (OK) -- only for < TLS 1.3
 Negotiated protocol          TLSv1.3
 Negotiated cipher            TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
 Cipher order
    TLSv1.2:   ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305
    TLSv1.3:   TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256


 Testing server defaults (Server Hello)

 TLS extensions (standard)    "renegotiation info/#65281" "EC point formats/#11" "key share/#51"
                              "supported versions/#43" "extended master secret/#23"
                              "application layer protocol negotiation/#16"
 Session Ticket RFC 5077 hint no -- no lifetime advertised
 SSL Session ID support       yes
 Session Resumption           Tickets no, ID: yes
 TLS clock skew               0 sec from localtime
 Signature Algorithm          SHA256 with RSA
 Server key size              RSA 2048 bits
 Server key usage             --
 Server extended key usage    --
 Serial / Fingerprints        754EDEA9 / SHA1 0B626941D68F533389ABD32D3A632D8F1E5590BD
                              SHA256 9C8C0FB52E92781BD8CFD50651E8664CF77BDD72A73031E228C2A539E0F4A4A3
 Common Name (CN)             classVsJar.organicdesign.org
 subjectAltName (SAN)         missing -- no SAN is deprecated
 Issuer                       self-signed (NOT ok)
 Trust (hostname)             certificate does not match supplied URI (same w/o SNI)
 Chain of trust               NOT ok (self signed)
 EV cert (experimental)       no
 ETS/"eTLS", visibility info  not present
 Certificate Validity (UTC)   1080 >= 60 days (2019-10-02 16:53 --> 2022-10-02 16:53)
 # of certificates provided   1
 Certificate Revocation List  --
 OCSP URI                     --
                              NOT ok -- neither CRL nor OCSP URI provided
 OCSP stapling                not offered
 OCSP must staple extension   --
 DNS CAA RR (experimental)    not offered
 Certificate Transparency     N/A


 Testing vulnerabilities

 Heartbleed (CVE-2014-0160)                not vulnerable (OK), no heartbeat extension
 CCS (CVE-2014-0224)                       not vulnerable (OK)
 Ticketbleed (CVE-2016-9244), experiment.  --   (applicable only for HTTPS)
 ROBOT                                     Server does not support any cipher suites that use RSA key transport
 Secure Renegotiation (RFC 5746)           supported (OK)
 Secure Client-Initiated Renegotiation     likely not vulnerable (OK), timed out
 CRIME, TLS (CVE-2012-4929)                not vulnerable (OK) (not using HTTP anyway)
 POODLE, SSL (CVE-2014-3566)               not vulnerable (OK)
 TLS_FALLBACK_SCSV (RFC 7507)              No fallback possible, no protocol below TLS 1.2 offered (OK)
 SWEET32 (CVE-2016-2183, CVE-2016-6329)    not vulnerable (OK)
 FREAK (CVE-2015-0204)                     not vulnerable (OK)
 DROWN (CVE-2016-0800, CVE-2016-0703)      not vulnerable on this host and port (OK)
                                           make sure you don't use this certificate elsewhere with SSLv2 enabled services
                                           https://censys.io/ipv4?q=9C8C0FB52E92781BD8CFD50651E8664CF77BDD72A73031E228C2A539E0F4A4A3 could help you to find out
 LOGJAM (CVE-2015-4000), experimental      not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
 BEAST (CVE-2011-3389)                     no SSL3 or TLS1 (OK)
 LUCKY13 (CVE-2013-0169), experimental     not vulnerable (OK)
 RC4 (CVE-2013-2566, CVE-2015-2808)        no RC4 ciphers detected (OK)


 Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.   Encryption  Bits     Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384                            
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256                      
 xc030   ECDHE-RSA-AES256-GCM-SHA384       ECDH 256   AESGCM      256      TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384              
 xcca8   ECDHE-RSA-CHACHA20-POLY1305       ECDH 253   ChaCha20    256      TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256        
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256                            
 xc02f   ECDHE-RSA-AES128-GCM-SHA256       ECDH 256   AESGCM      128      TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256              

Could not determine the protocol, only simulating generic clients.

 Running client simulations via sockets

 Android 4.4.2                TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 5.0.0                TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 6.0                  TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 7.0                  TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Android 8.1 (native)         TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Android 9.0 (native)         TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Chrome 65 Win 7              TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Chrome 74 (Win 10)           TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Firefox 62 Win 7             TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Firefox 66 (Win 8.1/10)      TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 IE 6 XP                      No connection
 IE 8 Win 7                   No connection
 IE 8 XP                      No connection
 IE 11 Win 7                  No connection
 IE 11 Win 8.1                No connection
 IE 11 Win Phone 8.1          No connection
 IE 11 Win 10                 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Edge 15 Win 10               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Edge 17 (Win 10)             TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Opera 60 (Win 10)            TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Safari 9 iOS 9               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 9 OS X 10.11          TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 10 OS X 10.12         TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 12.1 (iOS 12.2)       TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 253 bit ECDH (X25519)
 Safari 13.0 (macOS 10.14.6)  TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 253 bit ECDH (X25519)
 Apple ATS 9 iOS 9            TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Java 6u45                    No connection
 Java 7u25                    No connection
 Java 8u161                   TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Java 11.0.2 (OpenJDK)        TLSv1.3 TLS_AES_128_GCM_SHA256, 256 bit ECDH (P-256)
 Java 12.0.1 (OpenJDK)        TLSv1.3 TLS_AES_128_GCM_SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.0.1l               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.0.2e               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.1.0j (Debian)      TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 OpenSSL 1.1.1b (Debian)      TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
 Thunderbird (60.6)           TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)

 Done 2019-10-18 14:24:11 [  47s] -->> 127.0.0.1:8443 (localhost) <<--

 

On Fri, Oct 18, 2019 at 11:27 AM Young, Gregory <[hidden email]> wrote:

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: [hidden email] <[hidden email]> On Behalf Of Glen Peterson
Sent: October 18, 2019 10:30 AM
To: JETTY user mailing list <[hidden email]>
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 <[hidden email]> 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: [hidden email] <[hidden email]> On Behalf Of Simone Bordet
Sent: October 16, 2019 4:24 AM
To: JETTY user mailing list <[hidden email]>
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 <[hidden email]> 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: 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
[hidden email]
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
[hidden email]
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
[hidden email]
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


 

--

Glen K. Peterson
(828) 393-0081


 

--

Glen K. Peterson
(828) 393-0081


_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Supporting strong ciphers in IE11/Win7 (and 8.1)

Glen Peterson
Thanks for the details on having two certs in the keystore.

I tend to support a lot of devices, but the EC ciphers meet all my needs.  It seems like the only popular devices that require non-EC ciphers are too outdated to care about.  How does also having non-EC make things better?

On Tue, Oct 22, 2019 at 10:32 AM Young, Gregory <[hidden email]> wrote:

Source 1:

Gregory Young: "2. for the TLS_ECDHE_ECDSA_* ciphers to be available, you need to add a newer ECDSA signed SSL certificate to the keystore."  I was unable to add a second certificate to the keystore, but I was able to make a new keystore with an EC cert:

 

You need to use a different alias for the ECDSA signed cert in order to add it to the keystore alongside the RSA signed cert. This is how I do it in my self signed cert generation script:

 

  • /bin/keytool -importkeystore -srckeystore "${rsaPFX}" -srcstoretype "${srcKeystoreType}" -srcstorepass "${srcKeystorePassword}" -srcalias "${srcRSAAlias}" -keystore "${destKeystore}" -deststoretype "${keystoreType}" -deststorepass "${destKeystorePassword}" -destalias "${destRSAAlias}" -destkeypass "${destKeyPassword}"
  • /bin/keytool -importkeystore -srckeystore "${ecdsaPFX}" -srcstoretype "${srcKeystoreType}" -srcstorepass "${srcKeystorePassword}" -srcalias "${srcECDSAAlias}" -keystore "${destKeystore}" -deststoretype "${keystoreType}" -deststorepass "${destKeystorePassword}" -destalias "${destECDSAAlias}" -destkeypass "${destKeyPassword}"

Where:

  • destRSAAlias = “mycert”
  • destECDSAAlias = “mycert-ec”

 

 

Source 2:

testssl.sh shows the DHE ciphers supported by IE as weak, even though SSLLabs shows them green (strong).  I'm thinking weak is probably appropriate because of this: https://weakdh.org/

 

Make sure the DHE ciphers are at least 2048 bit, otherwise they are susceptible to weakDH. Some scanners throw the baby out with the bath water and declare all DH ciphers as weak, and at this time, this is untrue.

 

2. IE11/Win8.1 needs to see http1.1 first - before h2.

So I removed this line:

// alpn.defaultProtocol = "h2"

 

This is consistent with the alpn.ini config as suggested by the alpn.mod file:

 

# ---------------------------------------

# Module: alpn

# Enables the ALPN (Application Layer Protocol Negotiation) TLS extension.

# ---------------------------------------

--module=alpn

 

## Overrides the order protocols are chosen by the server.

## The default order is that specified by the order of the

## modules declared in start.ini.

jetty.alpn.protocols=h2,http/1.1

 

## Specifies what protocol to use when negotiation fails.

jetty.alpn.defaultProtocol=http/1.1

 

 

Gregory Young

 

From: [hidden email] <[hidden email]> On Behalf Of Glen Peterson
Sent: October 21, 2019 6:05 PM
To: JETTY user mailing list <[hidden email]>
Subject: Re: [jetty-users] Supporting strong ciphers in IE11/Win7 (and 8.1)

 

I figured it out.

 

1. Use an EC certificate:

sudo $JAVA_HOME/bin/keytool \

   -alias jetty \
   -dname "CN=classVsJar.organicdesign.org, OU=Testing, O=OrganicDesign, L=Upstate, ST=South Carolina, C=US" \
   -genkeypair \
   -keyalg EC \
   -keysize 256 \
   -keystore src/main/resources/keystore \
   -sigalg SHA256withECDSA \
   -storetype pkcs12 \
   -validity 1096

 

Source 1:

Gregory Young: "2. for the TLS_ECDHE_ECDSA_* ciphers to be available, you need to add a newer ECDSA signed SSL certificate to the keystore."  I was unable to add a second certificate to the keystore, but I was able to make a new keystore with an EC cert:

 

Source 2:

testssl.sh shows the DHE ciphers supported by IE as weak, even though SSLLabs shows them green (strong).  I'm thinking weak is probably appropriate because of this: https://weakdh.org/

 

2. IE11/Win8.1 needs to see http1.1 first - before h2.

So I removed this line:

// alpn.defaultProtocol = "h2"

 

Source 1:

Simone Bordet's comment on this issue:

 

Source 2:

As several people have alluded to, IE11 does not support http/2 on Windows 7 or 8.1: "Partial support [for Http2] in Internet Explorer refers to being limited to Windows 10."

 

Epilogue:

I'm probably going to have to support IE11/Win8.1 until January 2023:

"Windows 8.1 falls under the same lifecycle policy as Windows 8, and will reach end of Mainstream Support on January 9, 2018, and end of Extended Support on January 10, 2023."
Source:

 

On Fri, Oct 18, 2019 at 5:27 PM Glen Peterson <[hidden email]> wrote:

P.S. I posted a minimal sample project on Git (you may recognize it from my last question).

 

On Fri, Oct 18, 2019 at 3:46 PM Glen Peterson <[hidden email]> wrote:

Ok Simone, I did 4 tests:

 

1. Wireshark

 

I dumped the connection and protocol negotiation with wireshark as I issued an nmap ssl-enum-ciphers.  I don't know what I'm looking at, so I'm just attaching the dump file so that smarter minds than mine can figure it out.

 

2. -Djavax.net.debug=all

Running with:

$ java -Djavax.net.debug=all -jar target/ROOT.jar

 

Testing with:

$ nmap --script ssl-enum-ciphers -p 8443 localhost

 

I get one line of output in the application logs:

javax.net.ssl|DEBUG|0C|qtp518522822-12|2019-10-18 14:14:40.086 EDT|SunX509KeyManagerImpl.java:392|matching alias: jetty

 

3. openssl s_client

 

$ echo | openssl s_client -connect localhost:8443

CONNECTED(00000005)
depth=0 C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
verify return:1
---
Certificate chain
 0 s:C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
   i:C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDszCCApugAwIBAgIEdU7eqTANBgkqhkiG9w0BAQsFADCBiTELMAkGA1UEBhMC
VVMxFzAVBgNVBAgTDlNvdXRoIENhcm9saW5hMRAwDgYDVQQHEwdVcHN0YXRlMRYw
FAYDVQQKEw1PcmdhbmljRGVzaWduMRAwDgYDVQQLEwdUZXN0aW5nMSUwIwYDVQQD
ExxjbGFzc1ZzSmFyLm9yZ2FuaWNkZXNpZ24ub3JnMB4XDTE5MTAwMjIwNTMzNVoX
DTIyMTAwMjIwNTMzNVowgYkxCzAJBgNVBAYTAlVTMRcwFQYDVQQIEw5Tb3V0aCBD
YXJvbGluYTEQMA4GA1UEBxMHVXBzdGF0ZTEWMBQGA1UEChMNT3JnYW5pY0Rlc2ln
bjEQMA4GA1UECxMHVGVzdGluZzElMCMGA1UEAxMcY2xhc3NWc0phci5vcmdhbmlj
ZGVzaWduLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ56Z+Fv
W1iQsW19is/NCEVg7zoMJBzROosz/JhMXQfb2GDAc90mr9LcrNUVItHxBa1X14h+
6Pen8IOMon5zDUUCZ1HNqPbEIuUV4asTiWKKtGdLVU6dyljXHiXwnfhSFT8IALs8
AN9xYcJED0KJk21HRR5ZHJ/Focg0xTfuwgzMRDR1GUsYYDrveNKWyXK0/auH8pBv
Y4c1Mq7mK1UNZmWtj+lJs6jZm/WvZ6id8ZKhSvRHeFsYQWZ8RI7VkQn1uXQLOXW7
kOTbISNBYi775w2ryxzTRL7Iypo5E0cjVhBANOa7+S8TbBhLpZvW1vQbqe7Q6se9
QDgSmZ3pclrIlhMCAwEAAaMhMB8wHQYDVR0OBBYEFJJ4OYMqxaXoo3SdHa2zviae
/leOMA0GCSqGSIb3DQEBCwUAA4IBAQBLBo3H0M+4r6dVn6Kc2rDmugYOJyh2INtY
NlzmF6KrpFpF/ojx9Eb7n0tgU03W5Wxy5E3DTIrbaZGiinTeQDRcPmrN1xXpdyfq
kXxX9DtYOknEaimEytZEZuv934v7qeY+vaFoamixA+xcY1tyGdNSMJTkKCSS/8+u
OlVrIDjbTDVKJQ4iidKTyCZHi3jVvMboMPfQuyaN0xVHIdNz3yXQTOgoaBRpwOrr
vHS93GehMAx+GHez8BSINgxYyDIkL/PAfYH9ReSEp5wwTDczBcPvfbWePhB93dGS
xJEHtFH1MoWYH4fyk1VS8+Bcg7S6pYu1uBJrZzmEVLIbDZ1HrjJz
-----END CERTIFICATE-----
subject=C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org

issuer=C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1441 bytes and written 391 bytes
Verification error: self signed certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self signed certificate)
---
DONE

 

4. testssh.sh

This looks remarkably similar to the report running ssllabs.

 

$ ./testssl.sh localhost:8443

###########################################################
    testssl.sh       3.0rc5 from https://testssl.sh/dev/
    (f118085 2019-10-17 09:39:54 -- )

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.2-chacha (1.0.2k-dev)" [~183 ciphers]
 on glensDesktop:./bin/openssl.Linux.x86_64
 (built: "Jan 18 17:12:17 2019", platform: "linux-x86_64")


 Start 2019-10-18 14:23:25        -->> 127.0.0.1:8443 (localhost) <<--

 A record via:           /etc/hosts
 rDNS (127.0.0.1):       db.dev.memoryjoggerlibrary.com.dev.planbase.com.nethackwiki.com.nethack.wikia.com.www.steelypips.org.nethack.org.alt.org.ninjakiwi.com.gamesgames.com.playdos.games.classicreload.com.archive.org.playretrogames.com.ssega.com.myabandonware.com.www.cosumi.net.online-go.com.
 Service detected:       Couldn't determine what's running on port 8443, assuming no HTTP service => skipping all HTTP checks


 Testing protocols via sockets except NPN+ALPN

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      not offered
 TLS 1.1    not offered
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final
 NPN/SPDY   not offered
 ALPN/HTTP2 h2, spdy/3.1, http/1.1, grpc-exp, h2-fb, spdy/1, spdy/2, spdy/3, stun.turn, stun.nat-discovery, webrtc, c-webrtc, ftp (offered)

 Testing cipher categories

 NULL ciphers (no encryption)                  not offered (OK)
 Anonymous NULL Ciphers (no authentication)    not offered (OK)
 Export ciphers (w/o ADH+NULL)                 not offered (OK)
 LOW: 64 Bit + DES, RC[2,4] (w/o export)       not offered (OK)
 Triple DES Ciphers / IDEA                     not offered (OK)
 Average: SEED + 128+256 Bit CBC ciphers       not offered
 Strong encryption (AEAD ciphers)              offered (OK)


 Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4

 PFS is offered (OK)          TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 ECDHE-RSA-AES256-GCM-SHA384
                              ECDHE-RSA-CHACHA20-POLY1305 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256
 Elliptic curves offered:     prime256v1 secp384r1 X25519


 Testing server preferences

 Has server cipher order?     yes (OK) -- only for < TLS 1.3
 Negotiated protocol          TLSv1.3
 Negotiated cipher            TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
 Cipher order
    TLSv1.2:   ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305
    TLSv1.3:   TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256


 Testing server defaults (Server Hello)

 TLS extensions (standard)    "renegotiation info/#65281" "EC point formats/#11" "key share/#51"
                              "supported versions/#43" "extended master secret/#23"
                              "application layer protocol negotiation/#16"
 Session Ticket RFC 5077 hint no -- no lifetime advertised
 SSL Session ID support       yes
 Session Resumption           Tickets no, ID: yes
 TLS clock skew               0 sec from localtime
 Signature Algorithm          SHA256 with RSA
 Server key size              RSA 2048 bits
 Server key usage             --
 Server extended key usage    --
 Serial / Fingerprints        754EDEA9 / SHA1 0B626941D68F533389ABD32D3A632D8F1E5590BD
                              SHA256 9C8C0FB52E92781BD8CFD50651E8664CF77BDD72A73031E228C2A539E0F4A4A3
 Common Name (CN)             classVsJar.organicdesign.org
 subjectAltName (SAN)         missing -- no SAN is deprecated
 Issuer                       self-signed (NOT ok)
 Trust (hostname)             certificate does not match supplied URI (same w/o SNI)
 Chain of trust               NOT ok (self signed)
 EV cert (experimental)       no
 ETS/"eTLS", visibility info  not present
 Certificate Validity (UTC)   1080 >= 60 days (2019-10-02 16:53 --> 2022-10-02 16:53)
 # of certificates provided   1
 Certificate Revocation List  --
 OCSP URI                     --
                              NOT ok -- neither CRL nor OCSP URI provided
 OCSP stapling                not offered
 OCSP must staple extension   --
 DNS CAA RR (experimental)    not offered
 Certificate Transparency     N/A


 Testing vulnerabilities

 Heartbleed (CVE-2014-0160)                not vulnerable (OK), no heartbeat extension
 CCS (CVE-2014-0224)                       not vulnerable (OK)
 Ticketbleed (CVE-2016-9244), experiment.  --   (applicable only for HTTPS)
 ROBOT                                     Server does not support any cipher suites that use RSA key transport
 Secure Renegotiation (RFC 5746)           supported (OK)
 Secure Client-Initiated Renegotiation     likely not vulnerable (OK), timed out
 CRIME, TLS (CVE-2012-4929)                not vulnerable (OK) (not using HTTP anyway)
 POODLE, SSL (CVE-2014-3566)               not vulnerable (OK)
 TLS_FALLBACK_SCSV (RFC 7507)              No fallback possible, no protocol below TLS 1.2 offered (OK)
 SWEET32 (CVE-2016-2183, CVE-2016-6329)    not vulnerable (OK)
 FREAK (CVE-2015-0204)                     not vulnerable (OK)
 DROWN (CVE-2016-0800, CVE-2016-0703)      not vulnerable on this host and port (OK)
                                           make sure you don't use this certificate elsewhere with SSLv2 enabled services
                                           https://censys.io/ipv4?q=9C8C0FB52E92781BD8CFD50651E8664CF77BDD72A73031E228C2A539E0F4A4A3 could help you to find out
 LOGJAM (CVE-2015-4000), experimental      not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
 BEAST (CVE-2011-3389)                     no SSL3 or TLS1 (OK)
 LUCKY13 (CVE-2013-0169), experimental     not vulnerable (OK)
 RC4 (CVE-2013-2566, CVE-2015-2808)        no RC4 ciphers detected (OK)


 Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.   Encryption  Bits     Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384                            
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256                      
 xc030   ECDHE-RSA-AES256-GCM-SHA384       ECDH 256   AESGCM      256      TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384              
 xcca8   ECDHE-RSA-CHACHA20-POLY1305       ECDH 253   ChaCha20    256      TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256        
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256                            
 xc02f   ECDHE-RSA-AES128-GCM-SHA256       ECDH 256   AESGCM      128      TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256              

Could not determine the protocol, only simulating generic clients.

 Running client simulations via sockets

 Android 4.4.2                TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 5.0.0                TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 6.0                  TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 7.0                  TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Android 8.1 (native)         TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Android 9.0 (native)         TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Chrome 65 Win 7              TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Chrome 74 (Win 10)           TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Firefox 62 Win 7             TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Firefox 66 (Win 8.1/10)      TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 IE 6 XP                      No connection
 IE 8 Win 7                   No connection
 IE 8 XP                      No connection
 IE 11 Win 7                  No connection
 IE 11 Win 8.1                No connection
 IE 11 Win Phone 8.1          No connection
 IE 11 Win 10                 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Edge 15 Win 10               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Edge 17 (Win 10)             TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Opera 60 (Win 10)            TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Safari 9 iOS 9               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 9 OS X 10.11          TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 10 OS X 10.12         TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 12.1 (iOS 12.2)       TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 253 bit ECDH (X25519)
 Safari 13.0 (macOS 10.14.6)  TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 253 bit ECDH (X25519)
 Apple ATS 9 iOS 9            TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Java 6u45                    No connection
 Java 7u25                    No connection
 Java 8u161                   TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Java 11.0.2 (OpenJDK)        TLSv1.3 TLS_AES_128_GCM_SHA256, 256 bit ECDH (P-256)
 Java 12.0.1 (OpenJDK)        TLSv1.3 TLS_AES_128_GCM_SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.0.1l               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.0.2e               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.1.0j (Debian)      TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 OpenSSL 1.1.1b (Debian)      TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
 Thunderbird (60.6)           TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)

 Done 2019-10-18 14:24:11 [  47s] -->> 127.0.0.1:8443 (localhost) <<--

 

On Fri, Oct 18, 2019 at 11:27 AM Young, Gregory <[hidden email]> wrote:

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: [hidden email] <[hidden email]> On Behalf Of Glen Peterson
Sent: October 18, 2019 10:30 AM
To: JETTY user mailing list <[hidden email]>
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 <[hidden email]> 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: [hidden email] <[hidden email]> On Behalf Of Simone Bordet
Sent: October 16, 2019 4:24 AM
To: JETTY user mailing list <[hidden email]>
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 <[hidden email]> 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: 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
[hidden email]
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
[hidden email]
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
[hidden email]
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


 

--

Glen K. Peterson
(828) 393-0081


 

--

Glen K. Peterson
(828) 393-0081

_______________________________________________
jetty-users mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Supporting strong ciphers in IE11/Win7 (and 8.1)

Young, Gregory

My use case is a network appliance that needs to support all Microsoft supported versions of Windows, as well as MacOS and several flavours of Linux. If I recall correctly, EC was added in Windows 7, which means Server 2008 and Vista devices (yeah, I know, but our customers still demand we support them, and Microsoft hasn’t officially dropped support yet) require RSA. Additionally, as our customers purchase their own SSL certificates, and not every trusted CA is signing ECDSA certs yet, we also must support both, and in some cases both on the same server to support the older devices.

 

 

Gregory Young

 

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

 

Thanks for the details on having two certs in the keystore.

 

I tend to support a lot of devices, but the EC ciphers meet all my needs.  It seems like the only popular devices that require non-EC ciphers are too outdated to care about.  How does also having non-EC make things better?

 

On Tue, Oct 22, 2019 at 10:32 AM Young, Gregory <[hidden email]> wrote:

Source 1:

Gregory Young: "2. for the TLS_ECDHE_ECDSA_* ciphers to be available, you need to add a newer ECDSA signed SSL certificate to the keystore."  I was unable to add a second certificate to the keystore, but I was able to make a new keystore with an EC cert:

 

You need to use a different alias for the ECDSA signed cert in order to add it to the keystore alongside the RSA signed cert. This is how I do it in my self signed cert generation script:

 

  • /bin/keytool -importkeystore -srckeystore "${rsaPFX}" -srcstoretype "${srcKeystoreType}" -srcstorepass "${srcKeystorePassword}" -srcalias "${srcRSAAlias}" -keystore "${destKeystore}" -deststoretype "${keystoreType}" -deststorepass "${destKeystorePassword}" -destalias "${destRSAAlias}" -destkeypass "${destKeyPassword}"
  • /bin/keytool -importkeystore -srckeystore "${ecdsaPFX}" -srcstoretype "${srcKeystoreType}" -srcstorepass "${srcKeystorePassword}" -srcalias "${srcECDSAAlias}" -keystore "${destKeystore}" -deststoretype "${keystoreType}" -deststorepass "${destKeystorePassword}" -destalias "${destECDSAAlias}" -destkeypass "${destKeyPassword}"

Where:

  • destRSAAlias = “mycert”
  • destECDSAAlias = “mycert-ec”

 

 

Source 2:

testssl.sh shows the DHE ciphers supported by IE as weak, even though SSLLabs shows them green (strong).  I'm thinking weak is probably appropriate because of this: https://weakdh.org/

 

Make sure the DHE ciphers are at least 2048 bit, otherwise they are susceptible to weakDH. Some scanners throw the baby out with the bath water and declare all DH ciphers as weak, and at this time, this is untrue.

 

2. IE11/Win8.1 needs to see http1.1 first - before h2.

So I removed this line:

// alpn.defaultProtocol = "h2"

 

This is consistent with the alpn.ini config as suggested by the alpn.mod file:

 

# ---------------------------------------

# Module: alpn

# Enables the ALPN (Application Layer Protocol Negotiation) TLS extension.

# ---------------------------------------

--module=alpn

 

## Overrides the order protocols are chosen by the server.

## The default order is that specified by the order of the

## modules declared in start.ini.

jetty.alpn.protocols=h2,http/1.1

 

## Specifies what protocol to use when negotiation fails.

jetty.alpn.defaultProtocol=http/1.1

 

 

Gregory Young

 

From: [hidden email] <[hidden email]> On Behalf Of Glen Peterson
Sent: October 21, 2019 6:05 PM
To: JETTY user mailing list <[hidden email]>
Subject: Re: [jetty-users] Supporting strong ciphers in IE11/Win7 (and 8.1)

 

I figured it out.

 

1. Use an EC certificate:

sudo $JAVA_HOME/bin/keytool \

   -alias jetty \
   -dname "CN=classVsJar.organicdesign.org, OU=Testing, O=OrganicDesign, L=Upstate, ST=South Carolina, C=US" \
   -genkeypair \
   -keyalg EC \
   -keysize 256 \
   -keystore src/main/resources/keystore \
   -sigalg SHA256withECDSA \
   -storetype pkcs12 \
   -validity 1096

 

Source 1:

Gregory Young: "2. for the TLS_ECDHE_ECDSA_* ciphers to be available, you need to add a newer ECDSA signed SSL certificate to the keystore."  I was unable to add a second certificate to the keystore, but I was able to make a new keystore with an EC cert:

 

Source 2:

testssl.sh shows the DHE ciphers supported by IE as weak, even though SSLLabs shows them green (strong).  I'm thinking weak is probably appropriate because of this: https://weakdh.org/

 

2. IE11/Win8.1 needs to see http1.1 first - before h2.

So I removed this line:

// alpn.defaultProtocol = "h2"

 

Source 1:

Simone Bordet's comment on this issue:

 

Source 2:

As several people have alluded to, IE11 does not support http/2 on Windows 7 or 8.1: "Partial support [for Http2] in Internet Explorer refers to being limited to Windows 10."

 

Epilogue:

I'm probably going to have to support IE11/Win8.1 until January 2023:

"Windows 8.1 falls under the same lifecycle policy as Windows 8, and will reach end of Mainstream Support on January 9, 2018, and end of Extended Support on January 10, 2023."
Source:

 

On Fri, Oct 18, 2019 at 5:27 PM Glen Peterson <[hidden email]> wrote:

P.S. I posted a minimal sample project on Git (you may recognize it from my last question).

 

On Fri, Oct 18, 2019 at 3:46 PM Glen Peterson <[hidden email]> wrote:

Ok Simone, I did 4 tests:

 

1. Wireshark

 

I dumped the connection and protocol negotiation with wireshark as I issued an nmap ssl-enum-ciphers.  I don't know what I'm looking at, so I'm just attaching the dump file so that smarter minds than mine can figure it out.

 

2. -Djavax.net.debug=all

Running with:

$ java -Djavax.net.debug=all -jar target/ROOT.jar

 

Testing with:

$ nmap --script ssl-enum-ciphers -p 8443 localhost

 

I get one line of output in the application logs:

javax.net.ssl|DEBUG|0C|qtp518522822-12|2019-10-18 14:14:40.086 EDT|SunX509KeyManagerImpl.java:392|matching alias: jetty

 

3. openssl s_client

 

$ echo | openssl s_client -connect localhost:8443

CONNECTED(00000005)
depth=0 C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
verify return:1
---
Certificate chain
 0 s:C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
   i:C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDszCCApugAwIBAgIEdU7eqTANBgkqhkiG9w0BAQsFADCBiTELMAkGA1UEBhMC
VVMxFzAVBgNVBAgTDlNvdXRoIENhcm9saW5hMRAwDgYDVQQHEwdVcHN0YXRlMRYw
FAYDVQQKEw1PcmdhbmljRGVzaWduMRAwDgYDVQQLEwdUZXN0aW5nMSUwIwYDVQQD
ExxjbGFzc1ZzSmFyLm9yZ2FuaWNkZXNpZ24ub3JnMB4XDTE5MTAwMjIwNTMzNVoX
DTIyMTAwMjIwNTMzNVowgYkxCzAJBgNVBAYTAlVTMRcwFQYDVQQIEw5Tb3V0aCBD
YXJvbGluYTEQMA4GA1UEBxMHVXBzdGF0ZTEWMBQGA1UEChMNT3JnYW5pY0Rlc2ln
bjEQMA4GA1UECxMHVGVzdGluZzElMCMGA1UEAxMcY2xhc3NWc0phci5vcmdhbmlj
ZGVzaWduLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ56Z+Fv
W1iQsW19is/NCEVg7zoMJBzROosz/JhMXQfb2GDAc90mr9LcrNUVItHxBa1X14h+
6Pen8IOMon5zDUUCZ1HNqPbEIuUV4asTiWKKtGdLVU6dyljXHiXwnfhSFT8IALs8
AN9xYcJED0KJk21HRR5ZHJ/Focg0xTfuwgzMRDR1GUsYYDrveNKWyXK0/auH8pBv
Y4c1Mq7mK1UNZmWtj+lJs6jZm/WvZ6id8ZKhSvRHeFsYQWZ8RI7VkQn1uXQLOXW7
kOTbISNBYi775w2ryxzTRL7Iypo5E0cjVhBANOa7+S8TbBhLpZvW1vQbqe7Q6se9
QDgSmZ3pclrIlhMCAwEAAaMhMB8wHQYDVR0OBBYEFJJ4OYMqxaXoo3SdHa2zviae
/leOMA0GCSqGSIb3DQEBCwUAA4IBAQBLBo3H0M+4r6dVn6Kc2rDmugYOJyh2INtY
NlzmF6KrpFpF/ojx9Eb7n0tgU03W5Wxy5E3DTIrbaZGiinTeQDRcPmrN1xXpdyfq
kXxX9DtYOknEaimEytZEZuv934v7qeY+vaFoamixA+xcY1tyGdNSMJTkKCSS/8+u
OlVrIDjbTDVKJQ4iidKTyCZHi3jVvMboMPfQuyaN0xVHIdNz3yXQTOgoaBRpwOrr
vHS93GehMAx+GHez8BSINgxYyDIkL/PAfYH9ReSEp5wwTDczBcPvfbWePhB93dGS
xJEHtFH1MoWYH4fyk1VS8+Bcg7S6pYu1uBJrZzmEVLIbDZ1HrjJz
-----END CERTIFICATE-----
subject=C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org

issuer=C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing, CN = classVsJar.organicdesign.org

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1441 bytes and written 391 bytes
Verification error: self signed certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self signed certificate)
---
DONE

 

4. testssh.sh

This looks remarkably similar to the report running ssllabs.

 

$ ./testssl.sh localhost:8443

###########################################################
    testssl.sh       3.0rc5 from https://testssl.sh/dev/
    (f118085 2019-10-17 09:39:54 -- )

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.2-chacha (1.0.2k-dev)" [~183 ciphers]
 on glensDesktop:./bin/openssl.Linux.x86_64
 (built: "Jan 18 17:12:17 2019", platform: "linux-x86_64")


 Start 2019-10-18 14:23:25        -->> 127.0.0.1:8443 (localhost) <<--

 A record via:           /etc/hosts
 rDNS (127.0.0.1):       db.dev.memoryjoggerlibrary.com.dev.planbase.com.nethackwiki.com.nethack.wikia.com.www.steelypips.org.nethack.org.alt.org.ninjakiwi.com.gamesgames.com.playdos.games.classicreload.com.archive.org.playretrogames.com.ssega.com.myabandonware.com.www.cosumi.net.online-go.com.
 Service detected:       Couldn't determine what's running on port 8443, assuming no HTTP service => skipping all HTTP checks


 Testing protocols via sockets except NPN+ALPN

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      not offered
 TLS 1.1    not offered
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final
 NPN/SPDY   not offered
 ALPN/HTTP2 h2, spdy/3.1, http/1.1, grpc-exp, h2-fb, spdy/1, spdy/2, spdy/3, stun.turn, stun.nat-discovery, webrtc, c-webrtc, ftp (offered)

 Testing cipher categories

 NULL ciphers (no encryption)                  not offered (OK)
 Anonymous NULL Ciphers (no authentication)    not offered (OK)
 Export ciphers (w/o ADH+NULL)                 not offered (OK)
 LOW: 64 Bit + DES, RC[2,4] (w/o export)       not offered (OK)
 Triple DES Ciphers / IDEA                     not offered (OK)
 Average: SEED + 128+256 Bit CBC ciphers       not offered
 Strong encryption (AEAD ciphers)              offered (OK)


 Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4

 PFS is offered (OK)          TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 ECDHE-RSA-AES256-GCM-SHA384
                              ECDHE-RSA-CHACHA20-POLY1305 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256
 Elliptic curves offered:     prime256v1 secp384r1 X25519


 Testing server preferences

 Has server cipher order?     yes (OK) -- only for < TLS 1.3
 Negotiated protocol          TLSv1.3
 Negotiated cipher            TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
 Cipher order
    TLSv1.2:   ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305
    TLSv1.3:   TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256


 Testing server defaults (Server Hello)

 TLS extensions (standard)    "renegotiation info/#65281" "EC point formats/#11" "key share/#51"
                              "supported versions/#43" "extended master secret/#23"
                              "application layer protocol negotiation/#16"
 Session Ticket RFC 5077 hint no -- no lifetime advertised
 SSL Session ID support       yes
 Session Resumption           Tickets no, ID: yes
 TLS clock skew               0 sec from localtime
 Signature Algorithm          SHA256 with RSA
 Server key size              RSA 2048 bits
 Server key usage             --
 Server extended key usage    --
 Serial / Fingerprints        754EDEA9 / SHA1 0B626941D68F533389ABD32D3A632D8F1E5590BD
                              SHA256 9C8C0FB52E92781BD8CFD50651E8664CF77BDD72A73031E228C2A539E0F4A4A3
 Common Name (CN)             classVsJar.organicdesign.org
 subjectAltName (SAN)         missing -- no SAN is deprecated
 Issuer                       self-signed (NOT ok)
 Trust (hostname)             certificate does not match supplied URI (same w/o SNI)
 Chain of trust               NOT ok (self signed)
 EV cert (experimental)       no
 ETS/"eTLS", visibility info  not present
 Certificate Validity (UTC)   1080 >= 60 days (2019-10-02 16:53 --> 2022-10-02 16:53)
 # of certificates provided   1
 Certificate Revocation List  --
 OCSP URI                     --
                              NOT ok -- neither CRL nor OCSP URI provided
 OCSP stapling                not offered
 OCSP must staple extension   --
 DNS CAA RR (experimental)    not offered
 Certificate Transparency     N/A


 Testing vulnerabilities

 Heartbleed (CVE-2014-0160)                not vulnerable (OK), no heartbeat extension
 CCS (CVE-2014-0224)                       not vulnerable (OK)
 Ticketbleed (CVE-2016-9244), experiment.  --   (applicable only for HTTPS)
 ROBOT                                     Server does not support any cipher suites that use RSA key transport
 Secure Renegotiation (RFC 5746)           supported (OK)
 Secure Client-Initiated Renegotiation     likely not vulnerable (OK), timed out
 CRIME, TLS (CVE-2012-4929)                not vulnerable (OK) (not using HTTP anyway)
 POODLE, SSL (CVE-2014-3566)               not vulnerable (OK)
 TLS_FALLBACK_SCSV (RFC 7507)              No fallback possible, no protocol below TLS 1.2 offered (OK)
 SWEET32 (CVE-2016-2183, CVE-2016-6329)    not vulnerable (OK)
 FREAK (CVE-2015-0204)                     not vulnerable (OK)
 DROWN (CVE-2016-0800, CVE-2016-0703)      not vulnerable on this host and port (OK)
                                           make sure you don't use this certificate elsewhere with SSLv2 enabled services
                                           https://censys.io/ipv4?q=9C8C0FB52E92781BD8CFD50651E8664CF77BDD72A73031E228C2A539E0F4A4A3 could help you to find out
 LOGJAM (CVE-2015-4000), experimental      not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
 BEAST (CVE-2011-3389)                     no SSL3 or TLS1 (OK)
 LUCKY13 (CVE-2013-0169), experimental     not vulnerable (OK)
 RC4 (CVE-2013-2566, CVE-2015-2808)        no RC4 ciphers detected (OK)


 Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.   Encryption  Bits     Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384                            
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256                      
 xc030   ECDHE-RSA-AES256-GCM-SHA384       ECDH 256   AESGCM      256      TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384              
 xcca8   ECDHE-RSA-CHACHA20-POLY1305       ECDH 253   ChaCha20    256      TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256        
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256                            
 xc02f   ECDHE-RSA-AES128-GCM-SHA256       ECDH 256   AESGCM      128      TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256              

Could not determine the protocol, only simulating generic clients.

 Running client simulations via sockets

 Android 4.4.2                TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 5.0.0                TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 6.0                  TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Android 7.0                  TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Android 8.1 (native)         TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Android 9.0 (native)         TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Chrome 65 Win 7              TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Chrome 74 (Win 10)           TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Firefox 62 Win 7             TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Firefox 66 (Win 8.1/10)      TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 IE 6 XP                      No connection
 IE 8 Win 7                   No connection
 IE 8 XP                      No connection
 IE 11 Win 7                  No connection
 IE 11 Win 8.1                No connection
 IE 11 Win Phone 8.1          No connection
 IE 11 Win 10                 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Edge 15 Win 10               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Edge 17 (Win 10)             TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 Opera 60 (Win 10)            TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)
 Safari 9 iOS 9               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 9 OS X 10.11          TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 10 OS X 10.12         TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Safari 12.1 (iOS 12.2)       TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 253 bit ECDH (X25519)
 Safari 13.0 (macOS 10.14.6)  TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 253 bit ECDH (X25519)
 Apple ATS 9 iOS 9            TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Java 6u45                    No connection
 Java 7u25                    No connection
 Java 8u161                   TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 Java 11.0.2 (OpenJDK)        TLSv1.3 TLS_AES_128_GCM_SHA256, 256 bit ECDH (P-256)
 Java 12.0.1 (OpenJDK)        TLSv1.3 TLS_AES_128_GCM_SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.0.1l               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.0.2e               TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
 OpenSSL 1.1.0j (Debian)      TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
 OpenSSL 1.1.1b (Debian)      TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
 Thunderbird (60.6)           TLSv1.3 TLS_AES_128_GCM_SHA256, 253 bit ECDH (X25519)

 Done 2019-10-18 14:24:11 [  47s] -->> 127.0.0.1:8443 (localhost) <<--

 

On Fri, Oct 18, 2019 at 11:27 AM Young, Gregory <[hidden email]> wrote:

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: [hidden email] <[hidden email]> On Behalf Of Glen Peterson
Sent: October 18, 2019 10:30 AM
To: JETTY user mailing list <[hidden email]>
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 <[hidden email]> 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: [hidden email] <[hidden email]> On Behalf Of Simone Bordet
Sent: October 16, 2019 4:24 AM
To: JETTY user mailing list <[hidden email]>
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 <[hidden email]> 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: 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
[hidden email]
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
[hidden email]
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
[hidden email]
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


 

--

Glen K. Peterson
(828) 393-0081


 

--

Glen K. Peterson
(828) 393-0081

_______________________________________________
jetty-users mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users