James,
On 8/10/22 11:57, James H. H. Lampert wrote:
Interesting. The new "protocols" parameter.
Does this work with the traditional syntax? Can "protocols" and
"sslProtocol" coexist in the same Connector?
It's pretty important here to specify your Tomcat version number(s). I
see you have them at the bottom of this message, but not the original.
All our customer installations use JSSE security with a Java Keystore;
I've never configured a successful IBM Midrange installation any other way.
Looking at the "Server Information" on the "Manager" webapp, I see:
The "problem" server ("#2" in the original post) is on 8.5.73, running
under IBM OS/400 Java 8.0.5.25.
The "working" server ("#1" in the original post) is on 8.5.79, running
under IBM OS/400 Java 8.0.6.35.
I'm mostly going to repeat things others have said elsewhere in this
thread, but (a) all together and (b) with maybe some historical perspective.
Tomcat connectors have always supported the "sslProtocol" attribute
(which is next to useless, other than that you have to put something in
there that Java recognizes).
The other attribute used to be sslEnabledProtocols, now called
protocols, which is the one that actually sets the list of specific
protocol versions. Your versions should be sufficiently recent that the
following excerpts from the user manual[1] are currently accurate:
"
sslProtocol
JSSE only.
The SSL protocol(s) to use (a single value may enable multiple protocols
- see the JVM documentation for details). If not specified, the default
is TLS. The permitted values may be obtained from the JVM documentation
for the allowed values for algorithm when creating an SSLContext
instance e.g. Oracle Java 7. Note: There is overlap between this
attribute and protocols.
"
"
protocols
The names of the protocols to support when communicating with clients.
This should be a list of any combination of the following:
SSLv2Hello
SSLv3
TLSv1
TLSv1.1
TLSv1.2
TLSv1.3
all
Each token in the list can be prefixed with a plus sign ("+") or a minus
sign ("-"). A plus sign adds the protocol, a minus sign removes it form
the current list. The list is built starting from an empty list.
The token all is an alias for SSLv2Hello,TLSv1,TLSv1.1,TLSv1.2,TLSv1.3.
Note that TLSv1.3 is only supported for JSSE when using a JVM that
implements TLSv1.3.
Note that SSLv2Hello will be ignored for OpenSSL based secure
connectors. If more than one protocol is specified for an OpenSSL based
secure connector it will always support SSLv2Hello. If a single protocol
is specified it will not support SSLv2Hello.
Note that SSLv2 and SSLv3 are inherently unsafe.
If not specified, the default value of all will be used.
"
*These are not interchangeable*
Setting sslProtocols to a list of things may fail and certainly won't do
what you expect.
These days, you shouldn't even bother setting sslProtocol at all. Use
protocols and /only/ protocols and you'll get what you want.
I also highly recommend that you "upgrade" your configuration to use:
<Connector>
<SSLHostConfig protocols="stuff" ... />
</Connector>
There are certain things you cannot do without <SSLHostConfig> and
honestly it makes it WAY more clear in your configuration what you are
trying to do.
So why does it have to be this confusing? Well, history...
Long ago, there was just "SSL". Java at some point gave programmers the
option to use "TLS" which was this crazy new thing. If you wanted it,
you need to say "TLS" when initializing the SSLEngine component of Java.
When it was introduced into Tomcat 3.1 or whatever, that option was
added because hey, maybe not everyone wanted to live on the edge with
this new-fangled TLS thing. These days, it almost doesn't matter what
string you give to Java when initializing the SSLEngine, you always get
one that can do pretty much everything.
Okay, so at some point, we all switched from SSL to TLS and all was
good. Except that we had to disable SSLv3 at some point, and then these
new crazy people said we needed to support TLSv1.2, etc. and again not
everybody wanted that "secure" stuff they were happy with their ROT13
encryption and so sslEnabledProtocols was introduced: you could specify
not only which SSL engine you wanted (SSL vs TLS) but also the
individual protocols you were willing to support.
Fast-forward a few years and we have the situation where sslProtocols is
all but useless and mostly everyone wants to use TLSv1.2 and TLSv1.3 and
nothing else. But, backward-compatibility rules and so "all" (alias for
"SSLv2Hello,TLSv1,TLSv1.1,TLSv1.2,TLSv1.3") is the default. I've been
pushing for the default to be changed to support only the later
protocols and we are likely to do that in e.g. Tomcat 10.x but not other
versions because, again, history. Tomcat major versions have had a
lifetime of like 10 years and so we can't turn on a dime without
someone's whole cluster going down because we changed the defaults and
they didn't bother testing before releasing.
Hope that helps,
-chris
[1]
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support_-_SSLHostConfig
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
