Your challenge is much more with Java 8 as already mentioned above if you use a non-APR connector and with OpenSSL otherwise than with Tomcat itself.
----------------- Daniel Savard 2016-10-04 6:43 GMT-04:00 Garratt, Dave <dgarr...@logopak.net>: > 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 > > > >
