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. Someone did suggest using Apache HTTP server to do the comms - maybe and IIS connector to Tomcat would accomplish the same ? As I mentioned before I’m a bit of a novice with the server config. 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 >
