https://issues.apache.org/bugzilla/show_bug.cgi?id=54690
--- Comment #8 from Tim Whittington <t...@apache.org> --- For posterity, the actual situation with JSSE is a bit more complicated than client vs server. (The fix and workaround for this issue are correct - this is just to clarify the landscape in case it's ever come across again). Testing on Java 7 on OS X/Linux/HP-UX: There are 3 distinct sets of cipher suites obtainable from the 23! unique locations in the JSSE API that produce a list of cipher suites. There are 4 distinct sets of protocol variants obtainable from the 15! unique locations in the JSSE API that produce a list of protocols. I've attached a full report, but in summary: The cipher suites obtained are grouped into 3 distinct sets of ciphers: 1. Default ciphers for client objects (SSLContext and SSLSocketFactory/SSLSocket) for default and <= TLSv1.1 engines 2. Supported ciphers for all engines (i.e. they're all the same) 3. Enabled ciphers from server objects (SSLEngine, SSLServerSocketFactory and SSLServerSocket) for all engines, and client object defaults for TLSv1.2 engine The protocol variants are grouped into the following 4 sets: 1. Default for SSLContext and supported/default for SSLSocket in TLSv1.2 engine 2. Default for SSLContext and supported/default for SSLSocket in TLSv1.1 engine 3. Default for SSLContext and supported/default for all engines default and <= TLSv1 engines 4. Supported for SSLContext, supported/defaults for SSLEngine/SSLServerSocket in all engines For Java 6 on OS X/Linux/HP-UX, the results are a bit simpler: - Cipher suites are split into 2 groups: supported cipher suites, and default/enabled cipher suites (on all client + server objects). - For protocol variants, supported == enabled == default in all locations. For Java 7 on AIX: - Cipher suites are in 2 groups (supported and default/enabled), with client + server defaults the same. - Protocol variants are in 6 groups: 1. Defaults for client objects in Default engine (SSLv3, TLSv1) 2. Supported/default for client objects for TLSv1.2 engine (TLSv1.2 only) 3. Supported/default for client objects for TLSv1.1 engine (TLSv1.1 only) 4. Supported/default for client objects for TLS and TLSv1 engines (TLSv1 only) 5. Supported/default for client objects for SSL and SSLv3 engines (SSLV3 only) 6. Supported protocols for SSLContext, SSLEngine and SSLServerSocket on all engines, and defaults for SSLServerSocket on default engine (SSLv3+) (As an aside, all of this points out that in Java 7 switching the engine using the HTTPS connector protocol attribute will not only change defaults, but change the supported protocol variants that can be enabled). Cutting across all this: - Supported for SSLContext appears to be stable across the versions/platforms - the only way to reliably detect the 'server' defaults in a JVM appear to be via an SSLEngine or a SSLServerSocket constructed from an SSLContext. Thankfully the defaults appear to be independant of the engine (the protocol argument to SSLContext.getInstance()). -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
