Hi Chris,

The SSL_VERSION parameter was already defined by the vendor.

The web application we use allows users to connect to it via FTP, FTPS,
SSH, AS2, HTTPS, HTTP, etc. to transfer files through it to different back
end servers. The web application is a proxy.

Without me making the change to the predefined SSL_VERSION parameter that
was originally configured as "-Dhttps.protocols=TLSv1" to now be configured
to
"-Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2" (thank you for correcting my
typo) our remote party that uses and AS2 client that is locked down to only
using TLSv1.2 connection could now connect to us successfully and upload a
file. So with this change I was able to accomplish the client to connect to
the Tomcat server. But I am unable to accomplish a successful connection
when Tomcat is acting as the client to reach the remote AS2 server for us
to send a file to them. It appears we are not connecting to them using
TLSv1.2 and therefore we are dropped. I have a ticket open with the vendor
on this but they don't seem to be any help. I was trying to open the Java
console on the UNIX server but I am unable to as I do not have any X11
setup. I am unable to find a command line option to set what is allowed in
the Java application itself. On one of our test servers a colleague could
open the console and we saw that none of the TLS options were NOT enabled
and only SSLv3 was. I am not sure if this is the case with this server that
I am working on that we have an outside connection open to be able to work
with the outside customer.  I am unsure if this change would allow us to
reach them. I didn't know what the catalina.sh TLSv1.2 change versus
changing the Java application TLSv1.2 change is really responsible for. (I
know enough to brake stuff...lol) The vendor is not much help. It's very
frustrating so I reach out to this community and get the help I need.

Another interesting thing I found in my testing after the change to the
SSL_VERSION was in place was when I connected to the web application using
FTPS client using FileZilla in Debug mode to be able to see the connection
logging, not only was the key presented to the client from the server using
TLSv1.2 but the entire communication used TLSv1.2. Before the change only
the key was presented to the client using TLSv1.2 and the rest of the
communications showed TLSv1.0. So somehow the change to the SSL_VERSION
parameter allowed this. I am of course the kid that turns around and asks
"but why" :-)

-Joleen

On Fri, Jun 24, 2016 at 11:15 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Daniel,
>
> On 6/22/16 12:59 AM, Daniel Savard wrote:
> > 2016-06-21 19:08 GMT-04:00 Joleen Barker
> > <oldenuf2no...@gmail.com>:
> >
> >> Hello Daniel,
> >>
> >> Thank you for your replies.
> >>
> >> Yes, I have the Java build 1.7.0_71 installed and I have the
> >> Unlimited security package installed as the application from the
> >> vendor requires it.
> >>
> >> Ok, you say never to edit the catalina,sh. I can change it back.
> >> The settings originally was SSL_VERSION="-Dhttps.protocol=TLSv1"
> >>
> >>
> > I believe this is not from the original version of the file. I have
> > no longer any Tomcat 7 installed to check this, however if I am
> > checking my Tomcat 8 catalina.sh, there is no SSL_VERSION
> > environment variable anywhere. If you are having an already
> > modified catalina.sh, it will be difficult to provide any
> > meaningful guidance.
>
> +1
>
> No SSL_VERSION environment variable is recognized by a stock Tomcat.
>
> Furthermore, the system property "https.protocols" (not that it's
> plural, and Jolene had used the singular noun) only effects the
> default configuration for HttpsURLConnection and URL.openStream calls.
>
> https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_an
> d_https
>
> >> Why is it set for only one version in the catalina.sh what is
> >> having this set to one version limiting us to?
> >>
> >>
> > It seems your catalina.sh has already been modified by someone
> > else. This doesn't look like the vanilla version of the catalina.sh
> > file.
> >
> >
> >> Our connector has this set in it:
> >>
> >> sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" sslProtocol="TLS"
> >>
> >> Is this all we need to allow TLSv1.2 clients to come in and for
> >> Tomcat acting as a client to go out as TLSv1.2?
> >
> > You didn't provide enough details about your connector, so, read
> > this page:
> > https://tomcat.apache.org/tomcat-7.0-doc/config/http.html
>
> The above should be all you need. In fact, current Tomcat versions
> should out-of-the-box support TLSv1.0, TLSv1.1, and TLSv1.2 assuming
> that the JVM supports those protocols as well.
>
> > I assume you are configuring a NIO or BIO connector, then
> > sslProtocol="TLS" is the only needed attribute to support TLSv1,
> > TLSv1.1 and TLSv1.2. The sslEnabledProtocols attribute is not
> > necessary since it overalps with sslProtocol attribute. Note if you
> > do not specify this attribute it defaults to TLS anyway.
> >
> > If you read the documentation page above, you will see the
> > sslProtocol attribute is actually passing the value to Java 7.
> > That's why there is no need to temper with the catalina.sh to try
> > to set this for Java before hand. The proper way to configure
> > Tomcat is to modify files in the conf directory only. Playing with
> > files in bin and lib is not a recommended approach.
>
> +1
>
> Jolene, how are you determining that Tomcat is *not* handling TLSv1.2?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJXbU6fAAoJEBzwKT+lPKRYKmkP/0kJX7VVA/uQOUa/OBHR0JW8
> UvXgPLIpNkjCV7V5rPho1w6Tp+JYpdOvCEfU5baQB8ZX/rUKG6g9leQZOw7FPmTo
> uFnmGdXKjXj/BU/2YfjC85+y+pcHCOfDdHMsC9HObo0TIYJr9o2mKhuEBgvl8otD
> A8kNkzZZvbhSmvyQ5JJnurYF9P5n4QB/EsfwjOkHeMEP4ifwFXdXVBV2ozeTS4HP
> 0auydpdYnBlA1pkz0YSggW5kwr/NI/vcySCWIJC4SFMyMnz6z05YSxaGeDuAp3BI
> MHMytD/2+wxxAU8kdQQ++gcQqWF6ZNAyJETjOhWKvXWiNawLeV6ruubE1cvRo3PU
> BJv85qVLySbzs5eyCSVnypq9MMo8xRDTcd8N7/KNcu/FUUYaxQclaTFkPIBFYfn7
> bm3CFdqmUco1kg/Xsk4HIX3je2nubtQPXqhGerc3ax1SehVrEzQDB493/jEYrBYp
> RxXYbG2775x4QcN42VaQm4PiwwQUBymoKbm7utqeJMVLXbeBb6VSbWglw31ld2yl
> UN59V7yzWScB4HWppsb5RbmAyeNMqX/HFmZy1P2KuC8mHMHYwlcR8FYWx0iYlOZB
> iHR7Xf6LfaWyTHxGBMnBtdDXbJH77In1nKXw1Sucl6I0gZe0lHUAFy7tJHG+N/Pc
> SfDuRhaC0MDjIXEBuyA2
> =SA17
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Reply via email to