On 10/19/17, 10:02 AM, Christopher Schultz wrote:
The browser tells the server what cipher suites it supports during the initial handshake, and the server decides which algorithm to use. The client doesn't try multiple different connections to see which one sticks. The server either replies saying "okay, were using "suite X" or "go away, we can't talk to each other because we don't have any algorithms in common".
That actually makes a certain amount of sense, if the JVM somehow *thinks* it can handle certain ciphers (e.g., the ECDHE ciphers), but can't. And if the Midrange box JVMs are deferring cipher implementation to the OS, rather than implementing it internally, I can see how that could happen. I'll note that the ones that have ECDHE ciphers enabled, and aren't blowing up not only Chrome 60 but a bunch of simulated browser handshakes, are all on a much newer revision of the OS, one that, I think, supports ECDHE at the OS level, whereas the ones on which I had to disable ECDHE are on an OS revision that does NOT support it at the OS level.
Some pretty big assumptions, but if they're right, it would explain much. -- JHHL --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
