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<http://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]<mailto:[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]<mailto:[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<http://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<http://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<http://classVsJar.organicdesign.org>
i:C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU = Testing,
CN = classVsJar.organicdesign.org<http://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<http://classVsJar.organicdesign.org>
issuer=C = US, ST = South Carolina, L = Upstate, O = OrganicDesign, OU =
Testing, CN = classVsJar.organicdesign.org<http://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<http://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<http://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<http://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<http://127.0.0.1:8443>
(localhost) <<--
On Fri, Oct 18, 2019 at 11:27 AM Young, Gregory
<[email protected]<mailto:[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]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>> On
Behalf Of Glen Peterson
Sent: October 18, 2019 10:30 AM
To: JETTY user mailing list
<[email protected]<mailto:[email protected]>>
Subject: Re: [jetty-users] Supporting strong ciphers in IE11/Win7 (and 8.1)
1. enable "unlimited strength ciphers" in the Java security config.
I think I'm good using OpenJDK, but I checked:
$ echo $JAVA_HOME
/usr/lib/jvm/java-11-openjdk-amd64
$ ls -l /usr/lib/jvm/java-11-openjdk-amd64/conf/security/
total 4
lrwxrwxrwx 1 root root 41 Jul 18 14:21 java.policy ->
/etc/java-11-openjdk/security/java.policy
lrwxrwxrwx 1 root root 43 Jul 18 14:21 java.security ->
/etc/java-11-openjdk/security/java.security
lrwxrwxrwx 1 root root 37 Jul 18 14:21 nss.cfg ->
/etc/java-11-openjdk/security/nss.cfg
drwxr-xr-x 4 root root 4096 Aug 1 07:59 policy
vim /etc/java-11-openjdk/security/java.security
...
crypto.policy=unlimited
...
# Curious about this:
ssl.KeyManagerFactory.algorithm=SunX509
ssl.TrustManagerFactory.algorithm=PKIX
I'm curious about the SunX509. I do *not* set a keyManagerFactory (I'm a
server, not a client, and don't require client-side certificates). But when
Jetty starts up, I can see the following debugging info which I've just been
ignoring:
Unable to get KeyManagerFactory instance for algorithm [SunX509] on provider
[Conscrypt], using default
java.security.NoSuchAlgorithmException: no such algorithm: SunX509 for provider
Conscrypt
at java.base/sun.security.jca.GetInstance.getService(GetInstance.java:87)
at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:206)
at
java.base/javax.net.ssl.KeyManagerFactory.getInstance(KeyManagerFactory.java:195)
at
org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagerFactoryInstance(SslContextFactory.java:1817)
at
org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1275)
at org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:416)
at
org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:287)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
at
org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:92)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
at
org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:320)
at
org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:81)
at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:231)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at org.eclipse.jetty.server.Server.doStart(Server.java:385)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at org.organicdesign.classVsJar.ClazzVsJarKt.main(ClazzVsJar.kt:288)
2. for the "TLS_ECDHE_ECDSA_WITH_AES_*" ciphers to be available...
TLS_ECDHE_RSA_WITH_AES_* ciphers show up as available in Jetty debugging info
and are agreed upon by nmap (output of both are shown in my original message).
I spent an hour messing around with my keystore anyway, but nothing good
resulted.
3. Your Java or Jetty config have DHE ciphers disabled. I think the default
OpenJDK config has DHE less than 2048 bits disabled if I recall correctly.
Both TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 are showing in Jetty's "available ciphers"
debugging info, but are not available when I try to connect with nmap.
I noticed that the 4 strong ciphers that IE11/Win7 is said to support are
supported by openssl, but it has its own name for them. Not sure if that could
have anything to do with it. It looks in the TLS spec like they are identified
by some two-byte hex code and not a human-readable name, but I don't know:
$ openssl ciphers -stdname
...
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2
Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
...
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2
Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
...
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH
Au=RSA Enc=AESGCM(256) Mac=AEAD
...
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH
Au=RSA Enc=AESGCM(128) Mac=AEAD
...
Simone: I'll respond in a bit.
On Wed, Oct 16, 2019 at 3:53 PM Young, Gregory
<[email protected]<mailto:[email protected]>> wrote:
Probably one of 3 issues going on:
1. You need to enable "unlimited strength ciphers" in the Java security config.
2. for the "TLS_ECDHE_ECDSA_WITH_AES_*" ciphers to be available, you need to
add a newer ECDSA signed SSL certificate to the keystore (you can run both RSA
and ECDSA signed certs in parallel on the same Jetty instance).
3. Your Java or Jetty config have DHE ciphers disabled. I think the default
OpenJDK config has DHE less than 2048 bits disabled if I recall correctly.
Gregory Young
-----Original Message-----
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>> On
Behalf Of Simone Bordet
Sent: October 16, 2019 4:24 AM
To: JETTY user mailing list
<[email protected]<mailto:[email protected]>>
Subject: Re: [jetty-users] Supporting strong ciphers in IE11/Win7 (and 8.1)
Hi,
On Wed, Oct 16, 2019 at 12:03 AM Glen Peterson
<[email protected]<mailto:[email protected]>> wrote:
>
> According to Qualys SSL Labs, IE 11 on on Windows 7 and 8.1 only works with
> max TLS 1.2 and only supports the following 4 secure forward secrecy ciphers:
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
> Source:
> https://dev.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&pla
> tform=Win%207&key=143
>
> When I run nmap, those ciphers don't show up (SSL Labs reports the same):
> $ nmap --script ssl-enum-ciphers -p 8443 myDomain.com
>
> Starting Nmap 7.60 ( https://nmap.org ) at 2019-10-15 17:43 EDT Nmap
> scan report for myDomain.com (127.0.0.1) Host is up (0.000056s
> latency).
> rDNS record for 127.0.0.1<http://127.0.0.1>: localhost
>
> PORT STATE SERVICE
> 8443/tcp open https-alt
> | ssl-enum-ciphers:
> | TLSv1.2:
> | ciphers:
> | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
> | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
> | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (rsa 2048) - A
> | compressors:
> | NULL
> | cipher preference: server
> |_ least strength: A
>
> Nmap done: 1 IP address (1 host up) scanned in 0.30 seconds
>
>
>
> Jetty lists those ciphers as enabled:
>
> | += SslConnectionFactory@6dbb137d{SSL->alpn} - STARTED | +=
> |
> Server@5f058f00[provider=Conscrypt,keyStore=file:///home/folder/dev/etc/keystore,trustStore=null]
> - STARTED
> | | +> trustAll=false
> | | +> Protocol Selections
> | | | +> Enabled size=4
> | | | | +> TLSv1
> | | | | +> TLSv1.1
> | | | | +> TLSv1.2
> | | | | +> TLSv1.3
> | | | +> Disabled size=2
> | | | +> SSLv2Hello - ConfigExcluded:'SSLv2Hello' JVM:disabled
> | | | +> SSLv3 - ConfigExcluded:'SSLv3' JVM:disabled
> | | +> Cipher Suite Selections
> | | +> Enabled size=27
> | | | +> TLS_AES_128_GCM_SHA256
> | | | +> TLS_AES_256_GCM_SHA384
> | | | +> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
> | | | +> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
> | | | +> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
> | | | +> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
> | | | +> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
> | | | +> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> | | | +> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
> | | | +> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> | | | +> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
> | | | +> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
> | | | +> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> | | | +> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
> | | | +> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
> | | | +> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> | | | +> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> | | | +> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> | | | +> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
> | | | +> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
> | | | +> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
> | | | +> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
> | | | +> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
> | | | +> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
> | | | +> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> | | | +> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
> | | | +> TLS_EMPTY_RENEGOTIATION_INFO_SCSV
> | | +> Disabled size=18
> ...
>
>
>
> I'm using:
> Jetty version 9.4.21.v20190926
> Java: AdoptOpenJDK OpenJDK 64-Bit Server VM 11.0.4
> OS: Linux amd64 4.15.0-65-generic
>
> Why aren't they offered with tls 1.2? Can I fix this with configuration?
The only way to know for sure is to grab a network trace between client and
server and verify who is not offering the ciphers and why.
If you use Java, setting -Djavax.net.debug=all helps understanding what's going
on at the OpenJDK TLS implementation level (both on client and on server).
I'm inclined to think that the browser does not offer those ciphers, despite
what the link you reported says.
--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support from the Jetty & CometD
experts.
_______________________________________________
jetty-users mailing list
[email protected]<mailto:[email protected]>
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
[email protected]<mailto:[email protected]>
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
--
Glen K. Peterson
(828) 393-0081
_______________________________________________
jetty-users mailing list
[email protected]<mailto:[email protected]>
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
--
Glen K. Peterson
(828) 393-0081
--
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
