On 04.10.2016 09:53, Garratt, Dave wrote:
On 4 Oct 2016, at 08:48, André Warnier (tomcat) <a...@ice-sa.com> wrote:
On 04.10.2016 09:38, Garratt, Dave wrote:
I have Apache Tomcat 8 working ok with https when I connect to my web page
using a recent browser (desktop) or iPhone for example. However this specific
application is designed to run on a Motorola MC9090 hand held wireless barcode
scanner running a relatively old version of Windows Mobile. The browser on that
device can only load the HTTP page and not the HTTPS page, giving a unable to
open page message. Speaking to a “expert” on these scanners the consensus of
opinion is that the type of encryption used by Apache Tomcat 8 is more up to
date than the mobile devices browser can support. As it does not appear likely
that the mobile devices are going to be updated any time soon I was wondering
if its possible to force Tomcat to accept deprecated protocols rather than be
forced to revert to plain HTTP.
Any ideas or ideally an example of how this might look in a config file would
be most appreciated.
Naive question : if you are dealing anyway with old devices that cannot be
replaced by new devices, then why do you not just keep using the
correspondingly old version of tomcat and of the JVM ?
The requirement for HTTPS is only a recent requirement and the application is
now heavily dependent on Java 8. At this point I don’t know just how old a
version of Tomcat I would need to make it work and I would have to make
significant changes to the code in order to make it Java 6/7 compliant.
I was just wondering, basically because the reason for retiring an old SSL protocol is
usually that it has been proven insecure and/or buggy. So, there might be a way to do what
you are requesting, but it does not seem to make sense that the requirement for HTTPS is
recent (and presumably linked to a wish for increased security), yet for these old devices
the only way to do it, would be by enabling and old/buggy SSL protocol (and thus
potentially weaken other applications running on the same host). There seems to be a bit
of a logical thinking contradiction in this, no ?
To dig a bit deeper : there are two families of "connectors" which can be used
by Tomcat :
- the ones based on the underlying Java JVM's SSL
- the one based on the underlying APR (Apache Portable Runtime), which use
OpenSSL-based logic
If you wanted to enable an old deprecated protocol under the Java 8 JVM, you'd have to
look if this old protocol is even still supported by the Java 8 JVM. If not, though luck,
because the chances of persuading the vendor of this JVM to change their ways are probably
slim to say the least.
If you wanted to enable an old deprecated protocol in the APR-based connectors, your
chances may be a bit better (but not guaranteed), to find a working combination of
Tomcat/APR/OpenSSL which allows this and still works. But as time goes on, these things
will eventually get upgraded, and your old devices may get the problem again at some
unexpected moment.
You may also be facing issues then, if some security team scans your server, and finds out
that it is allowing a deprecated HTTPS protocol (which would show up even for accesses
having nothing to do with this application or these devices).
So if I was looking at this in a top-down way, I would tend to say that if really these
old devices need this "functionality", then whenever the server detects that it is talking
to one of these devices, it should redirect these calls to some other specific host or
service, where the HTTPS protocol has been intentionally weakened to support them, and
that this is well-documented and approved.
And the initial work to set this up, and its support after that, would then be clearly
identified and clearly attributable to the support of these old devices, without
interference with the new stuff.
That may also help the decision-makers to determine if the cost of supporting these old
devices is worth it or not.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
