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 11:59:31 GMT
On 04.10.2016 12:43, Garratt, Dave wrote:
> To elaborate, there is only this single application running on the server. All other
web applications use Windows IIS.
> I have mentioned that the problem is down to the old software on the scanner but it’s
a huge international organisation and making a upgrade to their entire line of devices is
likely to take some time.
> However silly it may seem this is a “tick the box” exercise when it comes to security
- HTTPS - yes/no.
> On the assumption that a weak encryption is better than none then I can’t really argue
with the customer.

Maybe you cannot argue with the customer, that is for your commercial environment to 
decide.  But on the professional ethics side of thing, I would disagree with you on the 
previous item.  A weak encryption can be worse than none, because it gives a false sense 
of security. It may lead the customer to think that he is protected, when in reality he is

not.  And it may be your duty as a technical adviser, to point this out.

And just to rub it in : if there is any question of potential future legal liability in 
this, I would seriously think about it.  What if in 6 months, someone breaks into the 
server and causes a lot of damage, taking advantage of one of the long-time known bugs of

the old HTTPS algorithm ? If this is really a major international corporation, do you 
think that their legal department would hesitate for a minute before starting to look if 
you have adequately warned them, and you have written proof of ditto ?

At least I would make sure that the correspondence shows something like "HTTPS encryption

according to the best method available, taking into account the well-known limitations of

the client device & software, as per our memo of ... ".

In other words, it may be a "tick the box" exercise for them; but that does not mean that

it is one for you, or for your employer.

> Someone did suggest using Apache HTTP server to do the comms - maybe and IIS connector
to Tomcat would accomplish the same ?

Yes. Basically, the schema is like

client device <- HTTPS -> IIS <-- (choice) --> Tomcat <- internal -> webapp
                        + connector

Assuming that IIS and Tomcat are running on the same host, the communication between IIS 
and Tomcat does not need to be encrypted (assuming the basic premise that the host itself

is not accessible to potential miscreants).

This kind of configuration is usually described as "terminating HTTPS at the front-end 
level", because the only place where HTTPS (and encryption) takes place, is between the 
client and the front-end IIS server. In this kind of configuration, it is still possible 
to know, for the Tomcat webapp, that the original client<->server communication /is/
HTTPS, and to react appropriately.

The (choice) element above, is because there are various methods/protocols available to do

the job. With IIS, you could use
- a simple proxying through HTTP, which would require some standard setup in IIS (I am not

familiar with it, so I don't really know how to do that)
- or an AJP connection. This requires an IIS add-on module available on the Tomcat 
website, and the corresponding setup.
See :,
and the "ISAPI redirector" would be the one you need.

AJP is not HTTP, it is another specific protocol, but it carries the same information as 
the HTTP protocol. To "talk AJP" between IIS and Tomcat, you need
- on the IIS side, the ISAPI redirector module
- on the Tomcat side, a <Connector> of the AJP kind.
   (see :

> As I mentioned before I’m a bit of a novice with the server config.

By the time you're done with this, you'll have become an expert.

But please before you do, heed the advice given by several contributors here, about this 
potentially weak HTTPS setup.

> Dave
>> On 4 Oct 2016, at 11:29, André Warnier (tomcat) <> wrote:
>> 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
>> 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:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message