Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Supporting strong ciphers in IE11/Win7 (and 8.1)

Hi,

On Wed, Oct 16, 2019 at 12:03 AM Glen Peterson
<glen.k.peterson@xxxxxxxxx> 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.


Back to the top