tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat)>
Subject Re: Tomcat 8 HTTPS issue with old browser
Date Tue, 04 Oct 2016 10:29:06 GMT
On 04.10.2016 09:53, Garratt, Dave wrote:

>> On 4 Oct 2016, at 08:48, André Warnier (tomcat) <> 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:
For additional commands, e-mail:

View raw message