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: https://github.com/eclipse/jetty.project/issues/2441#issuecomment-381614310 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." Source: https://caniuse.com/#feat=http2 *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: https://support.microsoft.com/en-us/help/18581/lifecycle-faq-windows-products On Fri, Oct 18, 2019 at 5:27 PM Glen Peterson <[email protected]> wrote: > P.S. I posted a minimal sample project on Git (you may recognize it from > my last question). > https://github.com/GlenKPeterson/classVsJar > > On Fri, Oct 18, 2019 at 3:46 PM Glen Peterson <[email protected]> > 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 < >> [email protected]> 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:* [email protected] <[email protected]> >>> *On Behalf Of *Glen Peterson >>> *Sent:* October 18, 2019 10:30 AM >>> *To:* JETTY user mailing list <[email protected]> >>> *Subject:* Re: [jetty-users] Supporting strong ciphers in IE11/Win7 >>> (and 8.1) >>> >>> >>> >>> *1. enable "unlimited strength ciphers" in the Java security config.* >>> >>> >>> >>> I think I'm good using OpenJDK, but I checked: >>> >>> $ echo $JAVA_HOME >>> /usr/lib/jvm/java-11-openjdk-amd64 >>> >>> >>> >>> $ ls -l /usr/lib/jvm/java-11-openjdk-amd64/conf/security/ >>> total 4 >>> lrwxrwxrwx 1 root root 41 Jul 18 14:21 java.policy -> >>> /etc/java-11-openjdk/security/java.policy >>> lrwxrwxrwx 1 root root 43 Jul 18 14:21 java.security -> >>> /etc/java-11-openjdk/security/java.security >>> lrwxrwxrwx 1 root root 37 Jul 18 14:21 nss.cfg -> >>> /etc/java-11-openjdk/security/nss.cfg >>> drwxr-xr-x 4 root root 4096 Aug 1 07:59 policy >>> >>> >>> >>> vim /etc/java-11-openjdk/security/java.security >>> >>> ... >>> >>> *crypto.policy=unlimited* >>> >>> ... >>> >>> *# Curious about this:* >>> >>> >>> *ssl.KeyManagerFactory.algorithm=SunX509 >>> ssl.TrustManagerFactory.algorithm=PKIX* >>> >>> >>> >>> I'm curious about the SunX509. I do *not* set a keyManagerFactory (I'm >>> a server, not a client, and don't require client-side certificates). But >>> when Jetty starts up, I can see the following debugging info which I've >>> just been ignoring: >>> >>> >>> >>> *Unable to get KeyManagerFactory instance for algorithm [SunX509] on >>> provider [Conscrypt], using default* >>> >>> java.security.NoSuchAlgorithmException: no such algorithm: SunX509 for >>> provider Conscrypt >>> at java.base/sun.security.jca.GetInstance.getService(GetInstance.java:87) >>> at >>> java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:206) >>> at >>> java.base/javax.net.ssl.KeyManagerFactory.getInstance(KeyManagerFactory.java:195) >>> at >>> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagerFactoryInstance(SslContextFactory.java:1817) >>> at >>> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1275) >>> at >>> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:416) >>> at >>> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:287) >>> at >>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) >>> at >>> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) >>> at >>> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117) >>> at >>> org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:92) >>> at >>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) >>> at >>> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) >>> at >>> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117) >>> at >>> org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:320) >>> at >>> org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:81) >>> at >>> org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:231) >>> at >>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) >>> at org.eclipse.jetty.server.Server.doStart(Server.java:385) >>> at >>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) >>> at org.organicdesign.classVsJar.ClazzVsJarKt.main(ClazzVsJar.kt:288) >>> >>> >>> >>> >>> >>> *2. for the "TLS_ECDHE_ECDSA_WITH_AES_*" ciphers to be available...* >>> >>> >>> >>> TLS_ECDHE_RSA_WITH_AES_* ciphers show up as available in Jetty >>> debugging info and are agreed upon by nmap (output of both are shown in my >>> original message). I spent an hour messing around with my keystore anyway, >>> but nothing good resulted. >>> >>> >>> >>> *3. Your Java or Jetty config have DHE ciphers disabled. I think the >>> default OpenJDK config has DHE less than 2048 bits disabled if I recall >>> correctly.* >>> >>> >>> >>> Both TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and >>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 are showing in Jetty's "available >>> ciphers" debugging info, but are not available when I try to connect with >>> nmap. >>> >>> >>> >>> I noticed that the 4 strong ciphers that IE11/Win7 is said to support >>> are supported by openssl, but it has its own name for them. Not sure if >>> that could have anything to do with it. It looks in the TLS spec like they >>> are identified by some two-byte hex code and not a human-readable name, but >>> I don't know: >>> >>> *$ openssl ciphers -stdname* >>> >>> *...* >>> >>> *TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - ECDHE-ECDSA-AES256-GCM-SHA384 >>> TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD* >>> >>> *...* >>> >>> *TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - ECDHE-ECDSA-AES128-GCM-SHA256 >>> TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD* >>> >>> *...* >>> >>> >>> *TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 >>> Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD ...* >>> >>> >>> *TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 >>> Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD ...* >>> >>> >>> >>> Simone: I'll respond in a bit. >>> >>> >>> >>> On Wed, Oct 16, 2019 at 3:53 PM Young, Gregory < >>> [email protected]> wrote: >>> >>> Probably one of 3 issues going on: >>> >>> 1. You need to enable "unlimited strength ciphers" in the Java security >>> config. >>> 2. for the "TLS_ECDHE_ECDSA_WITH_AES_*" ciphers to be available, you >>> need to add a newer ECDSA signed SSL certificate to the keystore (you can >>> run both RSA and ECDSA signed certs in parallel on the same Jetty instance). >>> 3. Your Java or Jetty config have DHE ciphers disabled. I think the >>> default OpenJDK config has DHE less than 2048 bits disabled if I recall >>> correctly. >>> >>> >>> Gregory Young >>> >>> >>> -----Original Message----- >>> From: [email protected] <[email protected]> >>> On Behalf Of Simone Bordet >>> Sent: October 16, 2019 4:24 AM >>> To: JETTY user mailing list <[email protected]> >>> Subject: Re: [jetty-users] Supporting strong ciphers in IE11/Win7 (and >>> 8.1) >>> >>> Hi, >>> >>> On Wed, Oct 16, 2019 at 12:03 AM Glen Peterson < >>> [email protected]> 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 >>> [email protected] >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://www.eclipse.org/mailman/listinfo/jetty-users >>> _______________________________________________ >>> jetty-users mailing list >>> [email protected] >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://www.eclipse.org/mailman/listinfo/jetty-users >>> >>> >>> >>> >>> -- >>> >>> Glen K. Peterson >>> (828) 393-0081 >>> _______________________________________________ >>> jetty-users mailing list >>> [email protected] >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://www.eclipse.org/mailman/listinfo/jetty-users >> >> >> >> -- >> Glen K. Peterson >> (828) 393-0081 >> > > > -- > Glen K. Peterson > (828) 393-0081 > -- Glen K. Peterson (828) 393-0081
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
