On 16/10/17 17:57, James H. H. Lampert wrote: > 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.
What changed? > 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? It is the server that appears to be rejecting the connection. Without knowing what has changed it is hard to speculate what might be triggering this. > 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? See previous response. > 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? What changed? Something must have. Client update? OS update? Java update? Tomcat update? Certificate expiry? Getting to the bottom of what changed would be the first step in finding what went on over the weekend. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
