Can somebody explain what just happened?
This morning, we got a call from a customer whose Tomcat server (on
their own hardware) we administer.
It seems that suddenly, and without any advance warning, all but the
oldest browsers were refusing to connect to the server, without offering
any override option. Dozens of their users were "left out in the cold,"
and unable to do their work.
I ran some tests of my own. Firefox 17 (Mac), for which I've blocked all
updates, connected just fine; Chrome 60 (Mac) was refusing to connect,
with extreme prejudice. I tried the same with our own Tomcat server, and
both browsers connected without complaint.
I then ran both sites through https://www.ssllabs.com/ssltest, and found
that our own Tomcat supported cipher suites
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
while theirs supported
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits FS WEAK
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits
RSA) FS
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits FS WEAK
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp521r1 (eq. 15360 bits
RSA) FS
Both were running Tomcat 7, both under Java 1.6. So I compared the
connector tags in the respective server.xml files, found that ours had a
"ciphers" clause restricting it to the two listed for it, while theirs
did not.
The obvious next step was to try removing the two DH ciphers, so I gave
them a "ciphers" clause accepting the other four protocols, restarted
Tomcat, cleared my Chrome cache, and tried connecting again. Still
refusing to connect, with extreme prejudice. Even tried shutting Chrome
down, relaunching it, clearing the cache, shutting it down again, and
relaunching it again, and still no change in behavior.
Finally, when I gave them the same "ciphers" clause we have on our
server, and restarted Tomcat again, everything started working properly.
I'll also note that the "Handshake Simulation" section of the SSLLabs
test showed 12 "Server sent fatal alert: internal_error" results for
both the "no ciphers clause" case and the "ECDHE" enabled case, but only
one (IE8/XP) for the "same ciphers clause as our own server" case.
But that leaves me with three big unanswered questions:
1. Why would a browser care about unsupported protocols if supported
ones were available?
2. My understanding is that DH is old, and considered weak, while ECDHE
is new, and considered extremely strong. So why do the ECDHE ciphers
still get rejected with extreme prejudice?
3. (and excuse me for screaming my head off; I'm not screaming AT
anybody) WHY DID THIS "REJECTION WITH EXTREME PREJUDICE" HAPPEN WITH
NEARLY ALL OF THE USERS OVER A WEEKEND, WITH NO WARNING AT ALL?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
