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 < [email protected]> 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:* [email protected] <[email protected]> *On > Behalf Of *Glen Peterson > *Sent:* October 21, 2019 6:05 PM > *To:* JETTY user mailing list <[email protected]> > *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: > > 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 -- 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
