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/ using
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 : http://tomcat.apache.org/connectors-doc/,
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 : http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html)
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) <a...@ice-sa.com> wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
